AI & Automation on 拾光集

How to Remove the AI Feel from Your Writing

Thu, 27 Aug 2026 12:38:00 +0800

Why AI-Generated Writing Often Feels Artificial

AI-generated text is usually easy to recognize for one reason: it often tries too hard to sound complete.

A sentence may be grammatically correct, logically structured, and professionally worded, yet still feel unnatural. This happens because AI tends to explain more than necessary, repeat the same idea in slightly different forms, and add conclusions even when the point is already clear.

For example:

Through this initiative, we aim to enhance the user experience, strengthen brand influence, and create a mutually beneficial situation for all parties involved.

There is nothing technically wrong with this sentence. The problem is that most of it says very little.

A more natural version would be:

This initiative focuses on improving the user experience and strengthening the brand, while creating clear benefits for users and partners.

The second version is not better because it sounds more casual. It is better because it gets to the point faster.

What to Look for Before Rewriting

Before rewriting AI-generated content, go through it sentence by sentence.

Do not immediately replace words or change sentence structures. First identify which parts actually need to be removed, shortened, or merged.

Pay particular attention to the following patterns.

1. Sentences That Are Too Perfectly Structured

AI often produces sentences that feel unusually balanced.

They may contain several parallel phrases, similar sentence lengths, or carefully arranged clauses. When every sentence follows the same polished structure, the writing starts to feel mechanical.

Good writing does not need to sound perfectly symmetrical.

If a sentence can express the same information more directly, simplify it.

2. Repeating the Same Point

AI frequently explains an idea, restates it, and then summarizes it again.

For example:

The software is designed to improve workflow efficiency. By reducing unnecessary manual operations, users can complete tasks more efficiently. This ultimately leads to a more streamlined and productive workflow.

These three sentences essentially make one point.

A cleaner version would be:

The software reduces repetitive manual work and helps users complete tasks faster.

The information is still there. The repetition is gone.

3. Unnecessary Conclusions

AI has a strong tendency to summarize.

A paragraph may already explain a point clearly, but the final sentence often repeats the same message with phrases such as:

Overall
In conclusion
Ultimately
This demonstrates that
This makes it an ideal solution
As a result
By doing so

These phrases are not automatically bad, but they should only stay when they add something.

If the conclusion simply repeats what the reader already understands, remove it.

4. Abstract Language

AI often replaces simple ideas with broad business language.

Common examples include:

enhance value
empower users
drive innovation
strengthen capabilities
create synergy
unlock potential
improve overall efficiency
achieve sustainable growth
create a win-win situation

Some of these phrases are useful in the right context. The problem is using them without explaining what actually changes.

Instead of:

The platform empowers teams to improve collaboration and unlock greater productivity.

Write:

The platform keeps tasks, comments, and files in one place, so teams spend less time switching between tools.

The second version gives the reader something concrete.

Remove “Correct but Useless” Sentences

One of the most useful editing rules is simple:

If removing a sentence does not change the facts, argument, or conclusion, consider deleting it.

Many AI-generated sentences sound reasonable but contribute almost nothing.

For example:

In today’s rapidly changing digital environment, businesses need to continuously adapt to evolving user expectations.

This statement is difficult to disagree with, but it may not help the reader understand the actual subject.

Unless that context is necessary, start with the real point.

Instead of:

In today’s rapidly changing digital environment, businesses need to continuously adapt to evolving user expectations. Our new platform provides an innovative solution designed to address these challenges.

Write:

Our new platform reduces the time required to manage customer requests by keeping messages, tasks, and status updates in one workspace.

Specific information is usually more persuasive than broad statements.

Reduce Mechanical Transitions

AI writing often relies heavily on transitions such as:

Firstly
Secondly
Additionally
Furthermore
Moreover
Meanwhile
Therefore
Consequently
In conclusion

These words are useful when they clarify relationships between ideas. They become distracting when every paragraph depends on them.

Good writing often moves naturally from one idea to another without announcing every transition.

For example:

Furthermore, the software also includes advanced search functionality. Additionally, users can filter results based on multiple criteria.

This can simply become:

The software also supports advanced search with multiple filters.

Fewer transitions usually make the writing feel more confident.

Avoid Forced Parallel Structure

Another common AI pattern is the three-part list:

faster, smarter, and more efficient

simple, intuitive, and powerful

improve productivity, enhance collaboration, and drive growth

Parallel structures are useful, but AI uses them too frequently.

When every product description contains three benefits and every paragraph ends with three outcomes, the writing becomes predictable.

Keep lists when the items are genuinely distinct. Otherwise, say what matters most.

Do Not Over-Explain Obvious Points

AI tends to explain information that the target audience probably already understands.

For example:

A search function allows users to enter keywords in order to find relevant files more quickly.

If the audience already understands what search does, this is unnecessary.

A better version might be:

Search results appear instantly as you type.

That tells the reader something useful about the product.

When editing, ask:

Does the reader need this explanation, or am I explaining something obvious?

Preserve Information Density

Removing AI-style writing does not mean making everything casual.

It also does not mean intentionally adding incomplete sentences, slang, spelling mistakes, or conversational filler.

The goal is not to imitate informal human speech.

The goal is to write like someone who knows the subject well enough to distinguish between important information and unnecessary explanation.

Professional writing can still be concise.

Technical writing can still feel natural.

Academic writing can still avoid unnecessary abstraction.

Good editing removes noise without removing substance.

A Practical Two-Step Editing Method

A reliable workflow is to separate diagnosis from rewriting.

Step 1: Identify What Should Change

Read the original text sentence by sentence and mark anything that should be:

deleted
shortened
merged
rewritten more specifically

For each sentence, identify the reason.

Common reasons include:

repeated information
no new information
abstract wording
excessive explanation
unnecessary conclusion
mechanical transition
template-like phrasing
too many modifiers

This prevents you from rewriting sentences simply because they “sound AI-generated.”

Every change should have a reason.

Step 2: Rewrite the Text

Once the weak parts are identified, rewrite the content while preserving:

facts
arguments
tone
technical terminology
important context
data
conclusions supported by evidence

Then remove anything that does not help the reader understand the subject or make a decision.

A Prompt You Can Use

The following prompt works well for product descriptions, event proposals, press releases, reports, articles, and academic summaries.

Review the text sentence by sentence and identify the parts that sound most like AI-generated writing.

Pay particular attention to:

- overly complete or perfectly structured sentences
- repeated explanations of the same point
- excessive summaries or conclusions
- abstract concepts and vague business language
- statements that sound correct but add no useful information
- mechanical parallel structures
- excessive transition words
- unnecessary explanations of obvious points

First, list the sentences that should be deleted, shortened, merged, or rewritten, and briefly explain why.

Then rewrite the full text while preserving its core facts, arguments, tone, logic, terminology, and important context.

During the rewrite:

1. Remove sentences that do not change the reader's understanding or judgment.
2. Merge repeated ideas.
3. Reduce unnecessary summaries.
4. Replace abstract language with specific information where possible.
5. Reduce mechanical transitions and forced parallel structures.
6. Say directly what can be said directly.
7. Preserve important facts, data, technical terms, and reasoning.

Do not intentionally add spelling mistakes, grammatical errors, slang, or incomplete sentences to make the text appear more human.

Do not reduce information density simply to make the writing more conversational.

The final version should sound like it was written by someone who genuinely understands the subject and knows which details matter.

Use this test when editing:

"If I delete this sentence, does the reader lose any important fact, reasoning, evidence, or context?"

If the answer is no, consider removing it.

The Most Important Editing Rule

The best way to make AI-generated writing feel more natural is not to make it sound more “human.”

It is to make every sentence earn its place.

A useful sentence should provide at least one of the following:

information
evidence
reasoning
context
judgment

If it does none of these, it probably does not need to be there.

The result is writing that is shorter without feeling thin, professional without sounding robotic, and clear without constantly explaining itself.

DeepSeek Harness 安装教程：让 DeepSeek V4 更稳定地接入 MCP、Claude Code 与 AI 编程工具

Sat, 15 Aug 2026 18:08:00 +0800

DeepSeek Harness 是一个针对 DeepSeek V4-Pro / V4-Flash 的第三方协议适配项目。

它不是 DeepSeek 官方客户端，也不是新的大模型，而是夹在 DeepSeek API 与 Claude Code、Cline、Roo Code、Cherry Studio 等 AI 工具之间的一层“适配器”，主要解决多轮推理、Tool Calling、流式输出、上下文和缓存等兼容问题。

目前项目提供 4 种主要使用方式：

Python Library
dsh 命令行工具
MCP Server
Claude Code / Agent Skill

如果主要用于 AI 编程，我更推荐 MCP + DeepSeek V4-Flash 这套组合。

一、安装前准备

至少需要：

Python 3
Node.js / npm
DeepSeek API Key
一个支持 MCP 的 AI 客户端

项目已经明确支持或适配 Claude Desktop、Cline、Roo Code、ChatWise、Cherry Studio 等 MCP 客户端。

DeepSeek API Key 可以从 DeepSeek Platform 获取。DeepSeek 官方目前的 Agent 集成文档也已经围绕 V4-Pro 和 V4-Flash 展开。

二、最推荐：通过 MCP 安装 DeepSeek Harness

实际上不需要把整个项目下载下来。

只需要：

`1`	`npx -y @deepseek-harness/mcp`

项目当前提供的 MCP 包为：

`1`	`@deepseek-harness/mcp`

它通过标准 stdio MCP 协议运行。

然后在支持 MCP 的客户端配置中加入：

{
  "mcpServers": {
    "deepseek-harness": {
      "command": "npx",
      "args": ["-y", "@deepseek-harness/mcp"],
      "env": {
        "DEEPSEEK_API_KEY": "你的 DeepSeek API Key"
      }
    }
  }
}

保存并重新启动客户端即可。

官方仓库给出的 MCP 配置也是这种方式。

DeepSeek Harness MCP 会提供几个主要工具：

deepseek_chat
deepseek_chat_stream
validate_message_history
estimate_cache_hit

其中后两个主要负责消息历史和缓存检查，本身不需要消耗 DeepSeek API 配额。

三、安装命令行版本

如果想先测试 DeepSeek Harness 是否能正常工作，可以安装 CLI：

`1`	`pip install deepseek-harness-cli`

Windows PowerShell 设置 API Key：

`1`	`$env:DEEPSEEK_API_KEY="你的API Key"`

Linux / macOS：

`1`	`export DEEPSEEK_API_KEY="你的API Key"`

然后运行：

`1`	`dsh doctor`

如果环境正常，就可以进入交互模式：

`1`	`dsh chat`

开启 Thinking：

`1`	`dsh chat -r`

还可以检查已有消息：

`1`	`dsh validate messages.json`

或者估算缓存命中：

`1`	`dsh estimate messages.json`

这些命令都来自项目当前 CLI 实现。

四、Python 项目安装

如果你正在开发自己的 Agent，可以直接安装 Python Library：

`1`	`pip install deepseek-harness`

简单测试：

from deepseek_harness import DeepSeekHarness

client = DeepSeekHarness(
    disable_thinking_by_default=True
)

response = client.chat(
    model="deepseek-v4-pro",
    messages=[
        {
            "role": "user",
            "content": "Hello"
        }
    ],
    max_tokens=4096
)

print(response["message"]["content"])

Python 方式更适合：

自己开发 AI Agent
FastAPI 后端
LangChain
LlamaIndex
自动化程序
企业内部 AI 系统

项目也将 Python Library 作为自定义 Agent 的推荐接入方式。

五、Claude Code 安装 Skill

DeepSeek Harness 本身还提供了一个 Claude Skill。

安装：

`1`	`git clone https://github.com/HenryZ838978/deepseek-harness`

然后复制：

`1`	`cp -r deepseek-harness/packages/skill ~/.claude/skills/deepseek-harness`

重新启动 Claude Code 后即可加载。

这个 Skill 主要让 Agent 理解 DeepSeek V4 的协议特性，包括：

Thinking / reasoning_content
Tool Calling
消息历史
DeepSeek Prefix Cache
API 调用规则

项目提供的 Skill 中还包含 safe_init.py 和协议参考文件。

Windows 用户也可以把：

`1`	`packages/skill`

复制到：

`1`	`C:\Users\你的用户名\.claude\skills\deepseek-harness`

六、推荐搭配哪些插件？

DeepSeek Harness 本身更像一个“模型协议层”，真正提升 Agent 能力的还是 MCP 和 Skills。

我比较推荐下面这套组合：

1. Context7

用途：

查询最新开发文档
框架 API
第三方库文档
代码示例

例如开发 Next.js、React、Python 时，可以减少模型使用旧 API 的情况。

2. Filesystem MCP

让 Agent：

读取文件
创建文件
修改代码
浏览项目目录

这是 AI 编程最基础的一类 MCP。

如果使用 Cline、Roo Code、Claude Code 等，本身已经拥有完整文件操作能力，就没必要重复安装。

3. Playwright MCP

适合 Web 项目。

可以让 Agent：

打开网页
点击按钮
填写表单
截图
检查页面
测试前端

对于 Codex / Claude Code / DeepSeek 做网站开发非常实用。

4. Git / GitHub

适合：

查看 Git diff
分析提交记录
管理 Issue
查看 PR
代码审查

如果 AI 经常帮你修改大型项目，Git 能让修改过程安全很多。

5. Sequential Thinking 类工具

适合复杂：

Bug 排查
系统架构
大型重构
复杂逻辑分析

不过 DeepSeek V4 本身已经具备 Thinking 能力，因此普通任务没有必要一直开启，否则可能增加 Token 消耗。

七、我更推荐的组合

如果主要目的是 使用 DeepSeek 做 AI 编程，可以这样搭：

DeepSeek V4-Flash
        ↓
DeepSeek Harness
        ↓
Cline / Roo Code / Claude Code
        ↓
MCP
├─ Context7
├─ Playwright
├─ GitHub
└─ 项目自身工具

日常写代码：

`1`	`DeepSeek V4-Flash`

复杂架构、疑难 Bug：

`1`	`DeepSeek V4-Pro`

这样通常比所有任务都直接跑 Pro 更合理。

DeepSeek Harness 值不值得安装？

如果只是：

1
2
3

简单聊天
普通 API 调用
单轮问答

其实没必要。

但如果你的场景是：

DeepSeek + Agent
DeepSeek + MCP
DeepSeek + Tool Calling
DeepSeek + AI 编程
长时间连续开发
多轮工具调用

DeepSeek Harness 就比较有价值。

因为它重点解决的不是“让 DeepSeek 变聪明”，而是让 DeepSeek V4 在 Agent 环境中的协议行为更加稳定。

需要特别注意的是：DeepSeek Harness 是社区项目，并非 DeepSeek 官方项目。

DeepSeek 官方目前另外维护了 awesome-deepseek-agent，里面已经收录 Claude Code、Codex、Cline、DeepSeek-TUI、Reasonix、OpenCode、Qwen Code 等大量 DeepSeek Agent 集成教程，可以作为后续扩展参考。

GitHub 项目

DeepSeek Harness：

`1`	`https://github.com/HenryZ838978/deepseek-harness`

DeepSeek 官方 Agent 集成项目：

`1`	`https://github.com/deepseek-ai/awesome-deepseek-agent`

项目当前采用 MIT License。

MiniMax H3 怎么本地部署？用 ComfyUI 搭建 AI 视频生成环境

Thu, 13 Aug 2026 22:44:00 +0800

MiniMax H3 已开放模型权重，也开始出现对应的 ComfyUI 工作流。

如果不熟悉 Python、CUDA 和模型目录，可以直接让 Codex、Claude Code 等 AI 编程工具协助部署：

安装 ComfyUI → 下载 H3 → 配置视频工作流 → 根据显卡调整参数 → 配置加速方案。

MiniMax H3 主要解决什么问题？

MiniMax H3 是一个开放权重多模态模型，支持文本、图片、视频和音频等输入。

在视频方向，更值得关注的是文生视频以及参考素材驱动的视频生成能力。

不过本地部署真正需要考虑的是：

显卡显存；
系统内存；
模型占用空间；
ComfyUI 节点兼容性；
生成分辨率和速度。

因此，不建议直接照搬别人的模型配置。

可直接复制的部署提示词

请帮我在 Windows 本地部署最新版 ComfyUI。

要求：

1. 安装最新稳定版 ComfyUI，并检查 Python、CUDA、PyTorch 和显卡驱动兼容性。

2. 创建 ComfyUI 启动 BAT 文件，并在 Windows 桌面创建快捷方式。

3. 下载并部署 MiniMax H3 官方开放权重模型。

4. 配置两套工作流：
   - 文本生成视频
   - 参考图片或参考素材生成视频

5. 下载模型前先检测：
   - GPU 型号
   - 显存
   - 系统内存
   - 硬盘剩余空间

根据本机配置选择能够运行的模型精度、分辨率和显存优化方式，不要默认下载最高配置。

6. 如果目前存在兼容 MiniMax H3 的 4-Step、LoRA 或其他加速方案：
   - 检查版本兼容性
   - 安装对应节点
   - 配置独立加速工作流
   - 保留原版工作流

7. 完成后输出：
   - ComfyUI 安装目录
   - 模型目录
   - 工作流位置
   - 桌面快捷方式
   - 当前推荐分辨率
   - 显存优化方式
   - 加速方案来源

8. 最后启动一次 ComfyUI，检查缺失节点、模型路径和 Python 依赖报错。

这段提示词最重要的一点，是要求 AI 先检测硬件，再决定模型和参数。

为什么不能直接按显存下载？

MiniMax H3 模型规模较大，本地运行不能简单理解成：

8GB 显存用一个版本，12GB 用另一个版本，24GB 就能满血运行。

实际还受到模型精度、CPU Offload、系统内存、分辨率和 ComfyUI 实现方式影响。

因此部署前至少应该先检查：

`1`	`nvidia-smi`

确认显卡和显存，再决定具体方案。

四步 LoRA 加速要注意什么？

目前社区已经出现 MiniMax H3 的四步和其他加速工作流，但这些方案不应直接理解成 H3 官方标准配置。

减少推理步数通常可以提升速度，但也可能影响：

视频细节；
动作稳定性；
提示词遵循度；
整体画质。

更合理的方法是同时保留：

1
2

MiniMax H3 原版工作流
MiniMax H3 四步加速工作流

这样可以自己比较速度与质量。

本地运行是不是只需要电费？

本地运行后，通常不再需要按照每条视频支付 API 或平台生成费用。

但并不是完全没有成本，还包括：

显卡和电脑硬件；
电费；
SSD 存储；
下载流量；
环境维护时间。

所以更准确的说法是：

部署完成后，主要运行成本来自本地硬件和电力，不再按生成次数单独付费。

是否值得部署？

如果本身有 NVIDIA 大显存显卡，而且经常生成 AI 视频，MiniMax H3 值得关注。

如果显存较小，只是偶尔生成视频，那么云端平台可能更省事。

本地部署最大的优势不是“完全免费”，而是可以自己控制模型、工作流和生成次数。

总结

MiniMax H3 开放模型后，可以通过 ComfyUI 搭建自己的本地 AI 视频生成环境。

比较合理的流程是：

检查硬件 → 安装 ComfyUI → 下载 H3 → 配置原版工作流 → 再测试四步加速。

不熟悉环境配置的话，可以直接把上面的提示词交给 Codex 或 Claude Code，让 AI 辅助完成安装和排错。

参考资料

MiniMax H3 官方项目
MiniMax H3 官方 Hugging Face
ComfyUI 官方项目
MiniMax H3 社区 ComfyUI 工作流

Agent-Reach：给 AI Agent 增加 Twitter、B站、小红书等联网能力

Thu, 13 Aug 2026 22:29:00 +0800

很多 AI Agent 本身可以调用工具，但真正需要它去搜索 Twitter/X、Reddit、B站、小红书等平台时，往往会遇到 API 收费、登录限制、反爬或工具配置复杂的问题。

Agent-Reach 做的事情，就是把这些分散的网络访问能力统一起来，让 Claude Code、Cursor 等支持 Agent/Skill 的工具，通过一套入口读取和搜索多个网站。

Agent-Reach 是什么？

Agent-Reach 是一个 MIT 协议开源项目。官方目前将它定位为 AI Agent 的互联网访问工具，可以统一安装、路由并检查不同平台所依赖的上游工具。

目前项目说明中涉及的平台包括：

Twitter / X
Reddit
YouTube
GitHub
Bilibili
小红书
LinkedIn
V2EX
雪球
小宇宙
RSS
普通网页
Web 搜索
Facebook、Instagram 等

并不是所有平台都能真正做到“安装后直接使用”。部分网站仍可能需要 Cookie、登录状态或者额外依赖。

它解决的主要问题

Agent-Reach 最有价值的地方，并不是单独提供一个“网页爬虫”，而是把不同的信息渠道统一成 Agent 可以调用的工具。

例如以前让 AI：

搜一下 GitHub 上这个项目最近的讨论，再看看 Reddit 和 Twitter 上有没有用户反馈。

可能需要分别配置 GitHub、Twitter、Reddit 的工具。

Agent-Reach 希望把这些访问方式统一管理，让 Agent 根据任务选择对应渠道。

这对于需要进行资料搜索、开源项目调研、社交平台信息收集、舆情查询的 Agent 会更加方便。

`agent-reach doctor` 检查配置

项目提供了一个比较实用的诊断命令：

`1`	`agent-reach doctor`

它主要用于检查各个平台对应的工具、配置和连接状态，方便判断哪些渠道已经可用、哪些仍缺少配置。

对于需要同时配置多个平台的用户来说，这比逐个平台排查方便不少。

它并不等于“真正无限制访问全网”

“让 AI 拥有全网视野”更适合作为项目定位，而不能理解成所有网站都可以无限制访问。

实际使用仍然受到几个因素影响：

1. 平台规则随时可能变化

Twitter、小红书、B站等平台可能调整登录验证、反爬机制或者接口规则。

今天可以工作的方式，并不代表以后一定继续有效。

2. 部分平台需要登录信息

涉及 Cookie 或账号授权时，需要特别注意账号安全，不建议直接把重要账号的完整凭证交给来源不明的脚本。

3. “零 API 费用”不代表完全没有成本

官方强调可以避免很多官方 API 费用，但使用过程中仍可能产生：

AI 模型 Token 费用；
搜索服务费用；
VPS 或服务器费用；
第三方工具服务费用。

因此更准确的理解应该是：尽量减少对付费平台 API 的依赖，而不是所有使用成本都为零。

Agent-Reach 适合谁？

比较适合：

使用 Claude Code、Cursor 等 Agent 工具的人；
经常让 AI 搜索 GitHub 和技术资料的人；
需要同时查询多个社区的信息；
想给自己的 AI Agent 增加联网搜索能力；
不希望分别维护大量平台工具的人。

如果只是偶尔搜索几个网页，直接使用浏览器或 AI 自带的 Web Search 反而更加简单，没有必要专门安装一套工具。

是否值得安装？

Agent-Reach 真正值得关注的地方，是它尝试解决一个越来越常见的问题：

模型本身已经足够聪明，但 Agent 能看到什么，很大程度取决于给它接入了哪些工具和信息源。

Agent-Reach 相当于在模型和互联网之间增加了一层统一的“渠道管理”。

对于经常使用 AI Agent 做资料调查、项目研究和跨平台搜索的人，它有一定实际价值。

但如果准备长期使用，建议重点观察项目维护状态，以及 Twitter、小红书、B站等第三方渠道在规则变化后的可用性，不要把当前支持列表理解成永久保证。

总结

Agent-Reach 是一个给 AI Agent 扩展互联网访问能力的开源工具，目前支持 Twitter/X、Reddit、YouTube、GitHub、B站、小红书等多个渠道，并通过统一 CLI 和 agent-reach doctor 降低多平台工具的配置和维护成本。

它比较适合需要让 Claude Code、Cursor 等 Agent 持续进行网络资料搜索的人。

不过，涉及登录 Cookie、第三方抓取以及平台反爬的网站，长期稳定性仍取决于平台规则和项目维护情况。这一点比“支持多少个平台”更值得关注。

Headroom 是什么？给 Claude Code、Codex 压缩上下文减少 Token

Thu, 13 Aug 2026 22:22:00 +0800

如果你经常使用 Claude Code、Codex、Cursor 这类 AI Agent，会发现 Token 不只是消耗在自己输入的问题上。

Agent 执行一次任务时，可能反复读取代码、终端输出、日志、JSON、搜索结果和历史上下文，其中不少内容最终都会进入模型。

Headroom 解决的就是这部分问题：先在本地把这些上下文压缩，再发送给 LLM。官方将它定位为 AI Agent 的“Context Compression Layer（上下文压缩层）”。

Headroom 是怎么减少 Token 的？

它并不是简单删除聊天记录。

按照官方目前的架构，Headroom 会识别不同类型的上下文，再使用不同方法处理，例如：

JSON、工具输出；
代码和文件；
日志；
RAG 检索结果；
对话历史。

处理流程大致可以理解成：

Claude Code / Codex / AI Agent
        ↓
日志、文件、工具输出、上下文
        ↓
      Headroom
        ↓
压缩后的上下文
        ↓
       LLM

Headroom 在本地运行，并且设计了可逆压缩机制。原始内容可以保存在本地缓存中，如果模型后续确实需要完整数据，可以再次获取，而不是单纯粗暴截断内容。

这也是它和“让 AI 回复简短一点”最大的区别。

Caveman 一类 Skill 更偏向减少模型输出内容，而 Headroom 主要处理进入模型之前的上下文。

到底能够省多少 Token？

这里需要区分场景。

Headroom 官方目前给出的参考范围是：

JSON 等结构化数据：约减少 60%～95%；Coding Agent：整体约减少 15%～20%。

项目仓库还公布了几个实际工作负载：

场景	原始 Token	压缩后	官方节省率
Code Search	17,765	1,408	92%
SRE 故障排查	65,694	5,118	92%
GitHub Issue 分类	54,174	14,761	73%
Codebase Exploration	78,502	41,254	47%

可以看出来，不存在所有任务固定节省 60%～95% 的情况。输入中 JSON、日志和重复信息越多，压缩空间通常越明显。

压缩之后会不会影响回答？

这也是 Headroom 最需要关注的问题。

官方公布的基准测试中，GSM8K 使用 100 个样本，Baseline 与 Headroom 都得到 0.870；TruthfulQA 测试则从 0.530 变为 0.560。项目还提供了对应测试方法用于复现。

但这里不能直接得出：

“Headroom 压缩后永远不会影响模型准确率。”

这些只能说明在项目方公布的测试条件下暂未观察到明显精度下降。

如果是大型代码库修改、复杂 Debug 或包含大量细节的长任务，最好还是自己做一次开启与关闭 Headroom 的对照测试。

哪些场景更适合 Headroom？

Headroom 更适合那些会大量读取外部内容的 AI Agent，例如：

Claude Code；
Codex；
Cursor；
大型项目代码分析；
大量终端日志排查；
JSON / API 返回数据处理；
RAG 知识库应用。

官方目前已经提供 Library、Proxy、MCP Server 以及 headroom wrap 等接入方式，并明确支持 Claude、Codex、Cursor、Aider 等工具。

如果只是偶尔问几句话，输入上下文本身只有几百 Token，那么专门部署 Headroom 的意义就没有那么大。

使用前需要知道的限制

Headroom 最大的价值并不是“让任何 AI 都省 95% Token”，而是减少 Agent 工作过程中大量机器生成上下文的浪费。

同时需要注意：

节省比例与任务类型高度相关；
60%～95% 不能直接套用到所有 Coding Agent；
引入上下文压缩层后，系统本身也会增加一定复杂度；
关键代码修改和复杂任务仍建议验证压缩前后的结果；
官方测试不能代替自己的真实使用环境测试。

总结

Headroom 的思路比较直接：

不要等一大堆日志、JSON 和工具输出进入 LLM 后再考虑 Token，而是在发送之前先压缩。

对于 Claude Code、Codex 这类频繁读取代码和工具输出的 Agent，这个方向确实具有实际价值。官方目前给出的 Coding Agent 参考节省幅度约为 15%～20%，而 JSON、日志等高冗余数据在特定场景下可能达到更高压缩比例。

至于能不能真正降低自己的 Token 消耗，最好还是用同一个真实项目分别开启、关闭 Headroom 跑一次，再比较输入 Token、任务结果和执行过程。

参考资料

Headroom 官方 GitHub：headroomlabs-ai/headroom
Headroom 官方 Documentation
项目许可证：Apache License 2.0

Caveman Skill 是什么？让 Claude Code、Codex 少说废话并减少输出 Token

Thu, 13 Aug 2026 22:13:00 +0800

用 Claude Code、Codex 这类 AI 编程 Agent 时，经常会遇到一个问题：明明只需要代码、命令或结论，AI 却先解释一大段，执行完还要再总结一次。

Caveman 就是为这种场景准备的 Skill。它不会让模型变聪明，也不会减少模型内部推理，而是尽量压缩最终回复，只保留代码、命令、结果和必要说明。

Caveman 能减少多少 Token？

Caveman 官方 Benchmark 对 10 个编程任务进行了对比，项目给出的结果是：

普通回复平均约 1214 Token，启用 Caveman 后约 294 Token，平均减少约 65%。

但这里需要注意两点：

这是项目方测试结果，不是本站实测；
它主要减少的是 Output Token，不是模型内部的 Reasoning / Thinking Token。

因此，更准确的理解是：

Caveman 让 AI “少说话”，而不是让 AI “少思考”。

它主要删掉哪些内容？

Caveman 会尽量减少：

客套和铺垫；
重复解释；
执行过程复述；
已完成内容的再次总结；
“如果需要我还可以……”之类的结尾。

例如你问：

`1`	`查询 Ollama 已安装模型`

普通 AI 可能先解释 Ollama 是什么，而 Caveman 模式更倾向直接给出：

`1`	`ollama list`

对于频繁使用 Codex、Claude Code 的人，这种交互方式会更干脆。

Caveman 怎么安装？

Windows

在 PowerShell 中运行：

`1`	`irm https://raw.githubusercontent.com/JuliusBrussee/caveman/main/install.ps1 \| iex`

macOS / Linux / WSL

`1`	`curl -fsSL https://raw.githubusercontent.com/JuliusBrussee/caveman/main/install.sh \| bash`

以上属于“下载脚本后直接执行”的安装方式。比较在意安全的话，建议先到 GitHub 查看 install.ps1 或 install.sh 内容，再决定是否运行。

安装后可使用：

`1`	`/caveman`

项目还提供不同压缩程度，例如：

1
2
3

/caveman lite
/caveman full
/caveman ultra

哪些场景适合使用？

Caveman 更适合目标明确的任务，例如：

查询命令；
修复报错；
修改代码；
运行测试；
查看执行结果；
让 Agent 完成重复性编程任务。

例如让 Codex：

`1`	`修复这个 Bug，运行测试，只告诉我修改内容和测试结果。`

这种任务本身并不需要大量解释，Caveman 的价值比较明显。

哪些情况不适合？

如果你正在：

学习陌生技术；
分析复杂架构；
排查安全问题；
比较多个方案；
希望理解 AI 的判断过程；

就不建议把输出压缩得太狠。

因为有些“解释”并不是废话，而是理解问题的重要信息。

因此比较合理的用法是：

执行任务时开启，学习和分析时关闭。

Caveman 值不值得装？

如果你经常使用 Claude Code、Codex、Cursor 等 AI Agent，而且已经受够每次执行完任务后的“小作文”，Caveman 值得尝试。

它最大的价值不是让模型能力变强，而是让回复更接近终端工具：

问命令就给命令，问报错就给原因，任务完成就告诉结果。

至于能省多少 Token，要看具体模型和任务。官方“平均约 65%”可以作为参考，但不能直接理解成安装后固定节省 65%。

总结

Caveman Skill 的作用很简单：减少 AI Agent 回复中的客套、复述和过度解释，提高有效信息密度。

它主要减少输出 Token，不会直接减少模型内部推理 Token。

如果你希望 Codex、Claude Code 少写“小作文”，它是一个值得关注的轻量 Skill；如果你的目标是大幅降低模型推理成本，那 Caveman 并不能解决这个问题。

DeepSeek 怎么识别图片？用 Reasonix + GLM-4V-Flash 添加免费视觉能力

Fri, 07 Aug 2026 20:23:00 +0800

DeepSeek 本身没有直接处理图片时，一个比较灵活的办法并不是更换主模型，而是给 Agent 增加一个专门负责图片分析的工具。

这次使用的是 Reasonix + MCP/Skill + 智谱 GLM-4V-Flash。平时依然让 DeepSeek 负责对话和任务处理，只有遇到图片时，再调用视觉模型完成识别。

简单理解就是：

图片 → Reasonix → 视觉 MCP → GLM-4V-Flash → 识别结果 → DeepSeek

这样做最大的意义，是不用为了偶尔看一张图片，就把整个 Agent 换成多模态模型。

DeepSeek 识图是怎么实现的？

这里首先要说明一个容易误解的地方：

这并不是让 DeepSeek 模型本身获得了视觉能力。

真正负责看图的是智谱的 GLM-4V-Flash，Reasonix 负责在需要识图时调用对应的 MCP 工具，再把返回结果交给 DeepSeek。

智谱官方目前将 GLM-4V-Flash 定义为免费的图像理解模型，支持图片描述、图片分类、图像问答等能力。

Reasonix 本身则支持 MCP、Skill 等扩展方式，因此两者可以组合起来使用。

第一步：申请智谱 API Key

首先进入智谱 AI 开放平台，注册账号并创建 API Key。

然后找到视觉模型：

`1`	`GLM-4V-Flash`

这里需要特别注意，网上部分视频或文章可能会将名称写成 GLM-4.6V Flash 或 GM-4.6V Flash。

根据目前智谱官方文档，免费的视觉模型名称是：

`1`	`GLM-4V-Flash`

发布文章或配置代码时，建议直接以智谱当前官方文档中的模型 ID 为准，避免因为名称变化导致 API 调用失败。

第二步：让 Reasonix 封装视觉 MCP

准备好智谱 API Key 后，可以直接让 Reasonix 帮忙创建一个调用视觉模型的 MCP Server。

例如可以给它类似这样的需求：

帮我封装一个 MCP Server，用于调用智谱 GLM-4V-Flash 视觉模型。

要求：
1. API Key 通过环境变量读取，不要直接写入代码。
2. 支持传入本地图片。
3. 支持输入图片和文字问题。
4. 返回视觉模型的文本分析结果。
5. 完成后告诉我如何安装和测试。

相比直接把 API Key 写进提示词或代码里，我更建议让它通过环境变量或者 Reasonix 的配置文件读取。

尤其是后续准备把 Skill 上传到 GitHub 时，更不能把自己的 API Key 一起提交。

第三步：把 MCP 封装成 Skill

MCP 创建完成并测试能够正常调用后，还可以进一步整理成 Reasonix Skill。

这样以后不需要每次告诉 DeepSeek：

`1`	`请调用 GLM-4V-Flash 分析这张图片`

而是让 Agent 根据任务判断什么时候需要使用视觉工具。

例如上传一张图片后直接问：

`1`	`图片上有什么内容。`

如果 Skill 的调用规则设置正确，Reasonix 就可以把图片任务交给视觉 MCP，再将分析结果返回给 DeepSeek。

实际识别效果

这次测试使用的是普通场景图片。

识别结果能够描述出图片中的：

*图片是一张浅蓝色背景的 Windows 桌面截图，上面有 4 个图标：

*右上角：深色图标，文字" 拾光集 “（可能是应用或网页快捷方式） *中间偏上：Word 文档图标，新建 DOCX 文档.docx *中间偏下：Word 文档图标，新建 DOC 文档(2).doc *底部：红色三角形图标（类似 VS Code），7.23作业（专项练习三）… *整体是学习/办公场景，主要在处理文档和作业文件。需要我针对某个图标或文件进一步分析吗？

至少在这种简单的自然场景描述任务里，可以正常工作。

不过目前没有继续进行 OCR、小字体截图、复杂图表、UI 界面定位以及大量图片的对照测试，所以还不能据此判断它在所有视觉任务中的准确率。

如果主要用途是：

看截图；
描述照片；
识别简单页面；
辅助分析图片内容；

这种方案已经具备实际使用价值。

如果是精确 OCR、复杂表格或者需要像素级判断的任务，则建议单独测试后再决定是否长期使用。

为什么不直接换一个多模态模型？

如果日常工作的大部分任务都是代码和文本，只有偶尔需要识图，这种“主模型 + 视觉工具”的方式其实更灵活。

DeepSeek 继续负责：

代码
↓
推理
↓
任务规划
↓
文字处理

碰到图片才调用：

`1`	`GLM-4V-Flash`

这样视觉模型更像是 DeepSeek 的一个外部工具，而不是替换 DeepSeek。

对于 Agent 来说，这种架构也比较常见：

DeepSeek
├── 文件工具
├── 浏览器工具
├── 搜索工具
├── 数据库工具
└── GLM-4V-Flash 视觉工具

需要什么能力，再调用什么工具。

使用前需要注意什么？

API Key 不要直接写入 Skill

这是最重要的一点。

不要把下面这种内容直接保存在公开代码中：

`1`	`API_KEY=你的真实Key`

应该使用环境变量或本地配置文件，并确保相关文件没有提交到 GitHub。

“免费”不代表永久没有限制

智谱官方目前将 GLM-4V-Flash 标记为免费视觉模型，但免费政策、调用频率以及模型名称以后都可能调整。

因此实际使用前建议重新查看官方文档，而不是长期依赖旧教程里的价格说明。

图片实际上会发送给第三方

使用这种方案后，需要识别的图片会提交给视觉模型服务商处理。

如果图片包含：

客户资料；
公司内部文件；
身份信息；
API Key；
密码；
未公开代码或业务数据；

不要在没有确认隐私要求的情况下直接上传。

是否值得给 DeepSeek 添加这个识图 Skill？

如果你正在使用 Reasonix + DeepSeek，同时又经常碰到截图、照片或者简单的图片分析任务，这种方案值得尝试。

它真正解决的问题并不是“让 DeepSeek 变成多模态模型”，而是：

给 DeepSeek Agent 增加一个可以随时调用的视觉工具。

文本和代码继续交给 DeepSeek，图片交给 GLM-4V-Flash，Reasonix 负责把两边连接起来。

从这次简单场景图片测试来看，这条调用链能够正常完成基本图片描述。不过复杂截图、OCR、图表理解等能力还有必要进一步测试。

总结

DeepSeek 没有直接识图能力，并不意味着 Agent 就一定不能处理图片。

借助 Reasonix + MCP/Skill + GLM-4V-Flash，可以把视觉模型作为一个外部工具，在需要处理图片时自动调用。

这种方式最大的优势不是“给模型升级”，而是把不同模型擅长的能力组合起来。

对于已经在 Reasonix 中使用 DeepSeek，又只是偶尔需要识图的人来说，比为了视觉能力完全更换主模型更灵活。

AI 阅读 PDF 太费 Token？先用 MarkItDown 转成 Markdown

Wed, 05 Aug 2026 13:27:00 +0800

直接把几十页甚至上百页的 PDF 上传给 AI，虽然方便，但不一定是最高效的处理方式。

PDF 本质上是一种面向打印和页面展示的格式。除了正文，它还可能包含页眉、页脚、页码、分栏、坐标定位、重复标题、隐藏文本和复杂表格等信息。AI 在解析文档时，可能需要额外处理这些排版结构，从而增加上下文长度和处理难度。

一种更适合长文档的工作流是：

先把 PDF 转成 Markdown，再让 AI 总结、问答或提取信息。

为什么 Markdown 更适合交给 AI？

Markdown 是结构清晰的纯文本格式，可以用简单符号保留文档中的重要层级，例如：

标题和章节
正文段落
有序列表和无序列表
表格
链接
代码块

与 PDF 相比，Markdown 通常会去掉大量只服务于页面展示的布局信息，让 AI 更容易识别文章结构。

这样做可能带来几个好处：

减少无关排版信息

页码、重复页眉和定位信息可能在转换时被简化，输入内容更加干净。
方便拆分长文档

可以按照一级标题、二级标题或者章节拆分 Markdown，分批交给 AI，避免一次提交整本 PDF。
便于搜索和引用

Markdown 可以直接使用文本编辑器搜索，也适合导入 Obsidian、知识库或 RAG 系统。
方便检查转换结果

在发送给 AI 之前，可以手动删除目录、版权页、重复页脚和无关章节。

需要注意的是，转换成 Markdown 不代表一定会减少 Token。最终消耗仍取决于转换后的文字长度、表格复杂度、OCR 结果以及你发送给 AI 的具体内容。

MarkItDown 是什么？

MarkItDown 是微软开源的一款 Python 工具，可以把多种文件转换成 Markdown，主要面向文本分析、内容索引和大语言模型处理场景。

目前项目支持的格式包括：

PDF
Word：DOCX
PowerPoint：PPTX
Excel：XLSX、XLS
HTML
CSV、JSON、XML
EPUB
ZIP 压缩包
图片和音频等文件

不同格式可能需要安装对应的可选依赖。项目也提供了插件机制，可扩展 OCR 等能力。

安装 MarkItDown

电脑需要先安装 Python，然后在终端中运行：

`1`	`pip install "markitdown[all]"`

[all] 会安装全部常用格式所需的依赖。

如果只需要转换 PDF，也可以只安装 PDF 相关组件：

`1`	`pip install "markitdown[pdf]"`

将 PDF 转换成 Markdown

进入 PDF 所在目录，运行：

`1`	`markitdown document.pdf -o document.md`

其中：

document.pdf 是原始 PDF 文件
document.md 是转换后生成的 Markdown 文件

转换完成后，可以使用 VS Code、Obsidian、Typora 或普通文本编辑器打开 .md 文件。

使用 Python 批量处理

需要集成到脚本或自动化流程时，可以使用 Python API：

from markitdown import MarkItDown

converter = MarkItDown()
result = converter.convert("document.pdf")

with open("document.md", "w", encoding="utf-8") as file:
    file.write(result.text_content)

这段代码会读取 document.pdf，并将转换结果保存为 document.md。

哪些 PDF 适合使用 MarkItDown？

MarkItDown 更适合：

文字型电子书
产品说明书
普通研究报告
合同和规章制度
Word 导出的 PDF
结构相对简单的论文
需要导入 AI 知识库的资料

哪些 PDF 可能转换效果不好？

以下类型需要谨慎检查：

扫描版 PDF
双栏或多栏论文
大量公式的学术文档
表格特别复杂的财务报告
图片中包含大量文字的文件
页面结构非常复杂的杂志
依赖图表位置才能理解的资料

MarkItDown 的 PDF 转换并不能保证完整还原复杂版式。项目维护者也曾说明，部分 PDF 的基础转换能力相对有限；对于复杂表格、扫描文件和学术排版，转换后可能需要手动整理，或者改用带版面识别和 OCR 能力的工具。

因此，不建议转换完成后直接删除原始 PDF。涉及合同、财务数据、论文公式或法律文件时，应同时对照原文核验。

总结

将 PDF 转成 Markdown，并不是单纯更换文件后缀，而是把面向页面展示的文档，整理成更适合 AI 阅读和检索的结构化文本。

对于文字较多、结构清晰的 PDF，这种方式可以减少排版干扰，并方便拆分章节、清理内容、建立知识库和进行多轮问答。

实际使用时可以记住三个步骤：

PDF 转 Markdown → 清理无关内容 → 按章节交给 AI

这样通常比直接上传整份长 PDF 更容易控制上下文，也更方便检查 AI 的回答是否来自原文。

项目地址

GitHub：Microsoft MarkItDown
Python 软件包：MarkItDown on PyPI

Video-use：用一句话让 AI 自动剪辑视频的开源技能

Tue, 04 Aug 2026 22:11:00 +0800

把原始素材放进文件夹，再告诉 AI“把这些素材剪成一条教程视频”，Video-use 就能协助完成素材分析、片段筛选、调色、字幕、动画叠加和视频渲染。

Video-use 是 Browser Use 团队开源的 AI 视频剪辑 Skill，可接入 Claude Code、Codex 等具备终端操作能力的 AI Agent。截至 2026 年 8 月，GitHub 已获得约 1.89 万颗 Star。

Video-use 可以做什么？

它主要适合已经拥有拍摄素材，希望通过自然语言快速完成剪辑的用户。

核心功能包括：

自动识别语音内容，删除“嗯”“啊”等语气词、口误和多余停顿
根据单词边界和静音区间选择剪辑点，减少截断语句的问题
为不同片段统一调色，支持暖色电影感、中性高对比和自定义 FFmpeg 参数
在每个剪辑点加入 30ms 音频淡入淡出，降低爆音和声音跳变
自动生成并硬编码字幕，字幕样式可以自定义
通过 HyperFrames、Remotion、Manim 或 PIL 添加动画图层
在输出前检查剪辑点、字幕遮挡、音频爆音和动画错位
将项目记录保存到 project.md，方便下次继续修改

项目采用“转录 → 内容整理 → AI 决策 → 生成剪辑表 → 渲染 → 自动检查”的工作流程。遇到问题时，会修正后重新渲染，最多进行三轮质量检查。

它是如何剪辑视频的？

Video-use 并不是把视频的每一帧都交给大模型分析。

它首先使用 ElevenLabs Scribe 获取逐词时间戳、说话人和音频事件，再将多个素材整理成体积较小的 takes_packed.md。AI 主要通过这份带时间轴的文字记录理解素材，只在需要判断停顿、动作或剪辑点时生成画面与波形预览。

确认剪辑方案后，Video-use 会生成：

edit/
├── project.md
├── takes_packed.md
├── edl.json
├── transcripts/
├── animations/
├── clips_graded/
├── master.srt
├── verify/
├── preview.mp4
└── final.mp4

其中：

edl.json 保存剪辑决策
master.srt 保存最终时间轴字幕
preview.mp4 用于预览
final.mp4 是最终成片
project.md 保存项目进度和修改记录

目前主要通过 helpers/render.py 完成片段提取、拼接、动画叠加和字幕渲染，并不是原文提到的 make_video.py。

安装前需要准备什么？

Video-use 本身采用 MIT 许可证开源，但完整使用还需要准备：

Claude Code、Codex 或其他支持 Skill 和终端操作的 AI Agent
Python 环境
FFmpeg 和 FFprobe
ElevenLabs API Key，用于语音转录
Node.js，仅在使用 HyperFrames 或 Remotion 动画时需要
yt-dlp，可选，用于下载在线视频素材

需要注意，Video-use 并不是完全离线运行。它当前依赖 ElevenLabs Scribe 完成逐词转录，因此可能产生 API 使用费用。

基本使用方法

安装并注册 Skill 后，进入保存视频素材的文件夹：

1
2

cd /path/to/your/videos
claude

使用 Codex 时，可以改为：

1
2

cd /path/to/your/videos
codex

然后直接输入剪辑要求：

1
2
3

把这些素材剪成一条 60 秒的产品介绍视频，
删除口误和长停顿，使用暖色调，
添加中文字幕和简单的重点文字动画。

AI 会先分析素材并提出剪辑方案，得到确认后才会开始处理，不会直接修改原始文件。最终结果会保存在素材目录下的 edit/final.mp4。

适合哪些使用场景？

Video-use 比较适合：

知识分享和口播视频
软件教程和产品演示
多段素材合并
Vlog 和旅行视频
访谈内容整理
需要反复修改的长期视频项目

它的优势不是完全替代专业剪辑师，而是把转录、粗剪、字幕、基础调色、动画叠加和质量检查整合到一个自然语言工作流中。

对于经常制作教程、口播或知识类内容的创作者，可以先让 Video-use 完成耗时的基础剪辑，再进行人工审片和细节调整。

项目地址

GitHub：browser-use/video-use
开源协议：MIT License

OpenMontage：开源 AI 全自动视频生产系统，从脚本到剪辑一条指令完成

Tue, 04 Aug 2026 22:05:00 +0800

OpenMontage：开源 AI 全自动视频生产系统，从脚本到剪辑一条指令完成

OpenMontage 是一个开源的 Agentic AI 视频生产系统。它不是单纯的文生视频模型，而是将选题研究、脚本创作、素材生成、配音、字幕、音乐、剪辑和最终渲染组织成完整的视频生产流水线。

用户可以直接在 Claude Code、Cursor、GitHub Copilot、Windsurf 或 Codex 等 AI 编程助手中描述视频需求，OpenMontage 会根据任务选择合适的制作流程，并调用本地工具或云端 AI 服务完成视频制作。

OpenMontage 可以做什么？

例如输入下面的指令：

`1`	`制作一条 60 秒的动画科普视频，主题是神经网络如何学习，需要中文旁白、背景音乐和字幕。`

系统会依次处理：

搜索并整理主题资料；
生成视频方案和脚本；
拆分场景与镜头；
搜索或生成图片、视频素材；
生成旁白、字幕和背景音乐；
使用 Remotion 或 FFmpeg 完成剪辑与渲染；
检查画面、音量、字幕和视频文件是否正常。

它也支持使用 Archive.org、NASA、Wikimedia Commons 等公开素材源搜索真实视频片段，而不只是把静态图片做成缩放动画。

当前主要功能

根据 OpenMontage 官方仓库目前的介绍，项目包含：

项目	当前规模
视频生产流水线	12 条
视频制作工具	100+
Agent Skill 与制作知识文件	700+

现有流水线覆盖多种视频类型，包括：

动画科普视频
产品宣传片与电影预告片
真人口播视频
软件操作演示
纪录片式素材混剪
播客转短视频
长视频批量切片
视频翻译、配音与本地化
AI 画面与真实素材混合剪辑

每条流水线都会按照类似下面的结构运行：

`1`	`资料研究 → 视频方案 → 脚本 → 分镜 → 素材 → 剪辑 → 合成`

OpenMontage 的核心并不是某一个 AI 模型，而是让 AI Agent 阅读 YAML 流水线配置、Markdown 导演指令和工具说明，再调用对应的 Python 工具执行任务。

是否可以完全免费使用？

部分流程可以不配置付费 API。

例如，OpenMontage 可以使用本地语音工具、公开素材库、开源视频工具和 Remotion 制作基础科普视频或真实素材混剪。

但是，制作 AI 动画、电影预告片或高质量产品广告时，通常需要配置图片生成、视频生成、语音合成或音乐生成服务。最终费用取决于所使用的模型、视频长度和素材数量。

因此，它更准确的定位是：

可以使用免费和本地工具运行，也可以接入付费 AI 服务提高画面质量，而不是所有视频都能完全零成本生成。

系统提供费用预估、预算上限和付费操作确认功能，可以降低批量生成时意外产生高额 API 费用的风险。

安装要求

运行 OpenMontage 前需要准备：

Python 3.10 或更高版本
FFmpeg
Node.js 18 或更高版本
Claude Code、Cursor、Copilot、Windsurf 或 Codex 等可读取文件并执行命令的 AI 助手

基础安装命令：

1
2
3

git clone https://github.com/calesthio/OpenMontage.git
cd OpenMontage
make setup

安装完成后，用 AI 编程助手打开项目目录，再输入需要制作的视频内容即可。官方也提供了无需 API Key 的演示流程，适合先检查本地环境是否配置成功。

OpenMontage 是否真的不需要人工操作？

OpenMontage 可以自动执行大量重复工作，但并不等于整个过程完全不需要用户参与。

在正式生成素材或调用付费模型之前，系统可能会展示：

视频创意方案
使用的模型与服务商
预计制作费用
场景和素材预览
渲染方案
需要确认的创意选择

这些确认步骤可以避免生成方向错误、素材不符合预期，或者在没有注意的情况下产生 API 费用。

因此，更适合将 OpenMontage 理解为一个 由 AI Agent 驱动的视频生产工作台，而不是输入一句话后完全不可控的黑盒视频生成器。

适合哪些用户？

OpenMontage 比较适合：

经常制作科普、教程或资讯视频的创作者；
需要批量生产短视频的内容团队；
希望把播客和长视频拆分成短内容的用户；
需要自动生成字幕、配音和多语言版本的团队；
熟悉 Codex、Claude Code 或 Cursor 的开发者；
想研究 AI Agent 视频工作流的人。

对于只想偶尔制作一条简单视频、又不熟悉命令行和 API 配置的普通用户，在线剪辑工具可能更容易上手。

使用前需要注意

不是所有流程都完全免费

本地工具和公开素材可以降低成本，但高级图片、视频和语音模型通常需要 API Key。
生成结果仍然需要审核

AI 可能出现事实错误、字幕错误、素材不匹配或音乐版权来源不清等问题，正式发布前应人工检查。
公开素材不代表可以随意使用

使用 Archive.org、Wikimedia Commons、Pexels 等来源时，仍需确认具体素材的授权范围和署名要求。
需要一定的本地环境配置能力

用户需要安装 Python、Node.js 和 FFmpeg，并能够处理依赖安装或 API 配置问题。
注意开源许可证

OpenMontage 当前采用 AGPL-3.0 许可证。修改项目并通过网络提供相关服务时，应先了解该许可证对源代码公开的要求。

总结

OpenMontage 的价值不只是“用 AI 生成一段视频”，而是把资料研究、脚本、分镜、素材、配音、字幕、剪辑和检查连接成一套可复用的自动化流程。

它适合希望提高视频生产效率、批量制作内容，或者想用 Codex、Claude Code、Cursor 构建 AI 视频工作流的用户。不过，高质量视频仍然需要合适的模型、素材审核和人工创意判断，不能简单理解为完全无人参与的一键出片工具。

项目地址

GitHub：https://github.com/calesthio/OpenMontage

AI 生成的网页总是缺少设计感？试试 Taste Skill 和 Impeccable

Tue, 04 Aug 2026 21:57:00 +0800

使用 Codex、Claude Code、Cursor 等 AI 编程工具制作网页时，经常会遇到类似问题：

页面布局过于模板化
默认使用渐变背景和大圆角卡片
字体、间距和视觉层级不统一
动效很多，但缺少明确目的
页面能运行，却看起来像“AI 批量生成”

Taste Skill 和 Impeccable 是两个针对 AI 前端设计的开源项目，可以为 AI 编程工具补充更具体的设计规则、检查流程和修改指令。

需要说明的是，它们主要优化的是网站、Web 应用和前端界面，并不能直接替代专业设计师，也不是通用的 AI 绘图或 PowerPoint 美化插件。

Taste Skill：减少模板化的 AI 网页设计

Taste Skill 是一个面向 AI 编程代理的开源设计 Skill，支持 Codex、Claude Code、Cursor、Gemini CLI 等工具。

它的重点不是提供固定网页模板，而是指导 AI 在生成前端时，更认真地处理：

页面布局与视觉重心
字体选择和字号层级
留白、间距与内容节奏
色彩、阴影和视觉深度
导航、Hero、功能区和 CTA 的组合
动效的速度、缓动和触发方式
常见“AI 味”设计模式的规避

例如，Taste Skill 会提醒 AI，不要每次都默认使用“左侧文字、右侧图片”的 Hero 布局，而是根据品牌和内容选择居中、错位、全屏背景、编辑式排版等方案。

安装 Taste Skill

在项目目录中运行：

`1`	`npx skills add Leonxlnx/taste-skill`

安装完成后，可以在提示词中明确要求 AI 使用 Taste Skill：

1
2
3

使用 Taste Skill 重新设计这个首页。

保留现有内容和功能，重点优化字体层级、留白、页面节奏和移动端布局，避免渐变背景、卡片堆叠和模板化 Hero。

不要只说“帮我做得高级一点”。同时告诉 AI 网站类型、目标用户、品牌气质和不希望出现的设计，效果会更稳定。

Impeccable：用 23 个设计命令检查和精修网页

原文中的“Impactful Skill”实际应为 Impeccable。

Impeccable 是一个面向 AI 编程工具的前端设计 Skill，内置 23 个设计命令，并提供针对常见 AI 前端问题的检测规则。它支持 Codex CLI、Claude Code、Cursor、Gemini CLI、GitHub Copilot 等工具。

常用命令包括：

polish：整体精修页面
audit：检查设计和实现问题
critique：分析当前页面的主要缺陷
typeset：优化字体、字号和文字层级
arrange：调整布局、间距和视觉节奏
colorize：改善配色与对比度
animate：优化动画和交互反馈
bolder：让过于保守的设计更有表现力
quieter：降低过度装饰和视觉噪音
distill：删除不必要的元素
harden：处理响应式、异常状态和生产环境细节

它不是简单地给页面套一套主题，而是让用户可以用更准确的设计词汇告诉 AI 应该修改什么。

安装 Impeccable

在项目根目录运行：

`1`	`npx impeccable install`

然后在支持的 AI 编程工具中执行初始化：

`1`	`/impeccable init`

初始化后，可以根据需要调用对应命令：

`1`	`/impeccable critique`

`1`	`/impeccable polish`

`1`	`/impeccable bolder`

也可以直接用自然语言描述任务：

1
2
3

使用 Impeccable 检查当前首页。

先分析字体、色彩、间距、信息层级和移动端布局，再修复最影响阅读体验的五个问题。保留现有品牌颜色和功能，不要大幅重写项目结构。

Taste Skill 和 Impeccable 有什么区别？

Taste Skill 更偏向建立整体设计方向，适合在创建页面、重做首页或确定视觉风格时使用。

Impeccable 更偏向诊断、检查和精修已有页面，适合页面已经完成，但仍然存在排版普通、间距混乱、视觉层级不清等问题时使用。

一个更实用的工作流是：

第一步：使用 Taste Skill 确定整体布局、字体层级和视觉方向。

第二步：完成页面代码和响应式适配。

第三步：使用 Impeccable critique 检查问题。

第四步：使用 Impeccable polish 进行整体精修。

第五步：根据结果继续执行 typeset、arrange、colorize 或 quieter。

使用时需要注意

这两个 Skill 可以提高 AI 对前端设计规则的执行能力，但最终效果仍然取决于：

原始需求是否具体
是否提供了品牌颜色和参考网站
页面内容是否完整
AI 是否能够查看或运行当前项目
是否进行了浏览器截图和移动端检查

对于电商详情图、亚马逊产品图或纯 AI 绘画，它们并不是专门的图像生成 Skill。对于 PPT，也需要 AI 工具本身支持幻灯片文件生成或编辑，不能仅靠安装前端设计 Skill 完成。

GitHub 项目地址

Taste Skill：

`1`	`https://github.com/Leonxlnx/taste-skill`

Impeccable：

`1`	`https://github.com/pbakaus/impeccable`

Codex 接入 DeepSeek V4 Flash，并通过 MCP 增加图片理解能力

Tue, 04 Aug 2026 19:53:00 +0800

DeepSeek V4 Flash 本身主要面向文本、编程和 Agent 任务。如果希望在 Codex 中使用 DeepSeek，同时让它能够分析截图、界面、报错图片或设计稿，可以采用下面这套组合方案：

Codex
  ├─ DeepSeek V4 Flash：负责推理、编程和工具调度
  ├─ Vision MCP：负责读取和分析图片
  └─ Skill：判断何时自动调用视觉工具

这并不是给 DeepSeek 模型本身增加视觉参数，而是让它在需要查看图片时，调用一个独立的视觉模型完成识图，再根据识图结果继续处理任务。

DeepSeek V4 Flash 是什么

DeepSeek 在 2026 年 4 月发布了 DeepSeek V4 Preview，其中包括：

DeepSeek V4 Pro：面向复杂推理和高难度 Agent 任务
DeepSeek V4 Flash：速度更快、调用成本更低
最高支持约 100 万 Token 上下文

2026 年 7 月 31 日，官方进一步更新了 DeepSeek-V4-Flash-0731。通过 DeepSeek API 使用 deepseek-v4-flash 模型名时，会自动指向当前更新版本。

V4 Flash 的主要优势不是在所有测试中超过旗舰模型，而是兼顾了价格、速度、长上下文和工具调用能力，更适合日常编程、代码修改以及 Agent 工作流。

模型评分会受到测试集、推理参数和评测平台影响，不建议只根据单一排行榜判断模型强弱。

第一步：备份 Codex 配置

在修改配置之前，先备份 Codex 的全局配置目录。

Windows PowerShell

`1`	`Copy-Item "$HOME\.codex" "$HOME\.codex-backup" -Recurse`

macOS 或 Linux

`1`	`cp -R ~/.codex ~/.codex-backup`

重点需要保留的内容通常包括：

1
2

~/.codex/config.toml
~/.codex/skills/

不同版本的 Codex 可能还会使用项目目录中的：

1
2

项目目录/.codex/config.toml
项目目录/.codex/skills/

不要把包含 API Key 的配置文件提交到公开 GitHub 仓库。

第二步：让 Codex 使用 DeepSeek

Codex CLI 支持通过 config.toml 配置模型和模型提供商，但第三方服务需要提供 Codex 所需的兼容接口。

DeepSeek API 支持 OpenAI 风格的接口，不过 Codex 对第三方模型的兼容性还取决于：

Codex 当前版本
DeepSeek API 接口类型
Responses API 与流式输出兼容情况
Tool Call 参数是否能够正确转换

因此，实际接入时可能需要直接配置 DeepSeek，也可能需要借助兼容代理层。

配置结构可参考：

model = "deepseek-v4-flash"
model_provider = "deepseek"

[model_providers.deepseek]
name = "DeepSeek"
base_url = "https://api.deepseek.com"
env_key = "DEEPSEEK_API_KEY"

API Key 建议通过环境变量保存。

Windows PowerShell

[Environment]::SetEnvironmentVariable(
  "DEEPSEEK_API_KEY",
  "你的 DeepSeek API Key",
  "User"
)

设置完成后重新打开终端。

macOS 或 Linux

`1`	`export DEEPSEEK_API_KEY="你的 DeepSeek API Key"`

然后启动 Codex：

codex

如果出现接口格式、Responses API 或 Tool Call 不兼容的问题，说明当前 DeepSeek 接口不能直接满足 Codex 的全部请求，需要增加一个兼容转换层，而不是反复修改 API Key。

第三步：配置视觉理解 MCP

DeepSeek V4 Flash 主要负责文本推理。图片分析可以交给 GLM-4.6V 或 GLM-4.6V-Flash。

Z.AI 官方提供了 Vision MCP Server，可为支持 MCP 的 AI 客户端增加：

图片内容分析
截图报错识别
网页界面理解
表格和图表分析
视频内容理解
视觉定位与界面操作辅助

其中，GLM-4.6V-Flash 当前提供免费调用选项，但免费额度、速率限制和开放政策可能调整，正式使用前应查看最新价格页面。

MCP 配置通常写入：

`1`	`~/.codex/config.toml`

结构示例：

[mcp_servers.vision]
command = "你的 Vision MCP 启动命令"
args = ["对应的启动参数"]
enabled = true

[mcp_servers.vision.env]
ZAI_API_KEY = "建议改用环境变量，不要直接填写在公开文件中"

实际的 command、args 和环境变量名称，应以所使用的 Vision MCP 项目说明为准。

配置完成后，重启 Codex，并检查 MCP 是否已经加载：

/mcp

也可以直接测试：

`1`	`请分析这张图片，告诉我图片中的报错原因，并给出修改步骤。`

如果 DeepSeek 能够返回视觉 MCP 的识别结果，说明工具链已经接通。

第四步：封装自动识图 Skill

只配置 MCP 后，模型不一定会在每次遇到图片时主动调用它。

可以再创建一个 Skill，明确告诉 Codex：

哪些任务需要调用视觉 MCP
应该先读取图片还是先询问用户
得到识图结果后如何继续处理
哪些情况下不应该调用视觉工具

Skill 可以放在：

`1`	`~/.codex/skills/image-understanding/`

例如创建：

`1`	`~/.codex/skills/image-understanding/SKILL.md`

参考内容：

# Image Understanding

当用户要求分析图片、截图、界面、设计稿、图表或图片中的错误信息时：

1. 优先调用 Vision MCP 获取图片内容。
2. 不要根据文件名猜测图片内容。
3. 提取图片中的文字、界面状态、关键元素和异常信息。
4. 将视觉结果与当前代码或任务上下文结合。
5. 给出可以执行的修改方案。
6. 图片无法读取时，明确说明失败原因，不要虚构识别结果。

这样，当用户输入类似下面的任务时，DeepSeek 就更容易自动调用视觉工具：

`1`	`查看这张报错截图，找到项目无法启动的原因。`

`1`	`分析这个网页截图，并根据现有项目修改页面布局。`

`1`	`读取图片中的配置内容，判断 MCP 是否启用成功。`

第五步：验证是否真正生效

建议分别测试三个层级。

1. 测试 DeepSeek

`1`	`请告诉我当前使用的模型提供商和模型名称。`

确认请求是否确实发送到了 DeepSeek，而不是仍在使用 Codex 默认模型。

2. 测试 Vision MCP

`1`	`调用视觉工具分析这张图片，并列出图片中的主要文字。`

确认 MCP 能被单独调用。

3. 测试自动识图 Skill

`1`	`这张图片为什么运行失败？`

不要主动写“请调用 MCP”，观察 Skill 是否会自动判断并使用视觉工具。

只有以上三个测试都成功，才能说明“DeepSeek + Codex + Vision MCP + Skill”的完整链路已经生效。

配置容易丢失的原因

需要注意，Codex 的全局配置、项目配置和不同客户端可能使用不同的配置层级。

以下操作可能导致自定义配置失效：

替换整个 config.toml
恢复旧版 Codex 配置
在桌面端和 CLI 之间切换配置
删除或重建 ~/.codex 目录
使用脚本覆盖原有配置文件
把 MCP 配置写在了错误的用户目录
在项目配置和全局配置中重复定义同名 MCP

曾有用户报告 Codex Desktop 在特定环境中重写全局配置，并移除手动添加的 MCP 项目。因此，修改前备份是必要的，但这不代表所有版本都会自动清除配置。

更加稳妥的做法是：

1. 先备份 ~/.codex
2. 先配置并验证 MCP
3. 再创建自动识图 Skill
4. 最后添加 DeepSeek 模型配置
5. 每完成一步都单独测试

不要一次覆盖整个配置文件。应把 DeepSeek 配置合并到现有配置中，保留原来的 MCP、Skill 和其他设置。

这套方案适合哪些任务

配置完成后，可以用于：

让 DeepSeek 根据报错截图修复代码
分析网页界面并修改前端样式
读取软件配置截图
从图表中提取数据
检查页面排版和视觉问题
分析图片中的终端输出
根据设计稿生成或调整代码

它的核心价值不是让 DeepSeek 直接变成多模态模型，而是利用 MCP 将文本模型、视觉模型和 Codex 的文件操作能力组合起来。

Cowart：为 Codex 加上无限画布，用标注直接修改 AI 图片

Tue, 04 Aug 2026 19:44:00 +0800

Cowart 是一款面向 Codex 的开源无限画布插件。它基于 tldraw 构建，可以在 Codex 中打开可视化画布，用于整理创意、放置参考图、生成图片、添加箭头和文字标注，以及根据标注继续迭代图片。

与只在聊天框里反复修改提示词相比，Cowart 更适合需要多轮调整的视觉创作任务。

Cowart 能做什么

Cowart 目前主要支持以下功能：

在 Codex 中打开 tldraw 无限画布
创建指定尺寸和比例的 AI 图片框
输入提示词并添加一张或多张参考图
让 Codex 将生成结果放入指定图片框
在图片上添加箭头、文字和图形标注
根据标注生成新的修改版本
在画布中保留原图、标注和不同版本
生成并嵌入单文件 HTML 页面
将图片和 HTML 内容整理成 AI Slides

画布数据默认保存在当前项目的 canvas/ 目录中，而不是上传或写入 Cowart 插件仓库。

为什么无限画布更适合 AI 改图

使用普通聊天窗口修改图片时，经常需要重新描述：

哪个物体需要调整
修改位置在哪里
哪部分应该保留
颜色、大小和方向如何变化

描述越复杂，提示词越容易出现歧义。

Cowart 将这些空间信息直接放到图片上。你可以圈出需要修改的区域，画一条箭头，再写上“删除这里的台灯”或“将沙发换成深棕色皮革”。

Cowart 会将原图、箭头和标注文字导出为截图，再交给 Codex理解修改要求并生成一个干净的新版本。

需要注意的是，这种方式本质上仍然是 AI 重新生成图片，并不等同于 Photoshop 的像素级局部编辑。复杂场景中，未标注区域也可能出现细节变化。

使用示例：生成中古风家居海报

第一步：打开 Cowart 画布

安装完成后，在 Codex 中输入：

`1`	`Open the Cowart canvas for this project.`

第二步：创建 AI 图片框

在画布工具栏中创建一个“AI 图片”框，并调整为需要的尺寸和比例。

例如，制作一张中古风家居海报，可以输入：

生成一张中古风家居海报。

画面是一间温暖的客厅，包含深棕色木质家具、焦糖色皮沙发、
复古落地灯和米白色地毯。使用低饱和暖色调、柔和侧光和
杂志广告式构图，保留顶部标题区域，图片比例为 4:3。

Cowart 会将提示词、参考图以及图片框的尺寸信息交给 Codex，并用生成结果替换这个图片框。

第三步：直接标注需要修改的位置

生成图片后，可以在画布中：

圈出不需要的家具
用箭头指出需要移动的位置
写明需要替换的颜色或材质
标出需要保留的区域

例如：

删除这个花瓶
沙发改为深棕色皮革
标题区域增加留白
窗外改成傍晚街景

选中带有标注的图片，点击“按标注修改”。

Cowart 会将标注截图发送给 Codex，并把新生成的图片放在原图旁边。原图和标注不会被删除，方便继续比较和迭代。

安装 Cowart

最简单的方法是把下面的内容直接发送给 Codex：

请从 https://github.com/zhongerxin/cowart.git 安装 Cowart Codex 插件。

请将仓库克隆到 ~/plugins/cowart，
确认 .codex-plugin/plugin.json 文件存在，
然后将插件加入 personal marketplace。

依次运行：

codex plugin marketplace add ~
codex plugin add cowart@personal

安装完成后，请校验插件是否可用，
并告诉我是否需要新建 Codex 对话来加载 Skill 和 MCP 工具。

也可以手动安装：

mkdir -p ~/plugins
git clone https://github.com/zhongerxin/cowart.git ~/plugins/cowart
cd ~/plugins/cowart
npm install
npm run build

codex plugin marketplace add ~
codex plugin add cowart@personal

安装完成后，建议新建一个 Codex 对话，让 Cowart 的 Skill 和 MCP 工具完整加载。

适合哪些使用场景

Cowart 比较适合：

AI 海报与网站封面设计
电商产品图修改
室内设计方案对比
UI 页面和网页原型迭代
图片版本管理
演示文稿视觉素材整理
需要频繁圈选和标注的改图任务

它的核心价值并不是让 AI 图片绝对精准，而是把“用文字描述位置”变成“直接在画面上指出位置”，降低人与 AI 之间的沟通成本。

使用前需要注意

Cowart 是 Codex 插件，需要先具备可使用插件和 MCP Widget 的 Codex 环境。
图片生成和修改仍会消耗对应模型额度。
标注越清晰，生成结果通常越容易接近期望。
一次修改的内容不要过多，建议分成多轮完成。
重要文字、Logo 和商品细节应在生成后人工检查。
当前项目采用 MIT 开源许可证，但生成图片所涉及的素材版权仍需自行确认。

项目地址

GitHub：zhongerxin/Cowart
底层画布框架：tldraw/tldraw

Codex 如何节省 Token：用 GPT-5.6 Sol 管理、Luna 执行是否可行？

Tue, 04 Aug 2026 19:38:00 +0800

Codex 如何节省 Token：用 GPT-5.6 Sol 管理、Luna 执行是否可行？

可以，但不能简单理解成“所有写代码任务都交给 Luna Max”。

更准确的做法是把 Codex 工作流拆成两个角色：

GPT-5.6 Sol 负责决策：分析需求、拆解任务、确定架构、处理复杂问题和最终审查。
GPT-5.6 Luna 负责执行：修改指定文件、补充测试、修复明确 Bug、批量重构和运行检查。

这种方式类似让 Sol 当项目负责人，让 Luna 处理边界清晰的开发任务。

为什么这样可以降低 Codex 消耗？

Codex 目前按照输入 Token、缓存输入 Token 和输出 Token 计算 credits。

按照 OpenAI 当前公布的费率：

模型	输入 Token	输出 Token
GPT-5.6 Sol	125 credits / 100 万	750 credits / 100 万
GPT-5.6 Terra	50 credits / 100 万	300 credits / 100 万
GPT-5.6 Luna	5 credits / 100 万	30 credits / 100 万

相同 Token 数量下，Luna 的 credits 消耗大约只有 Sol 的 1/25。

因此，把大量代码读取、修改和测试工作交给 Luna，通常能够显著降低总体消耗。

但实际节省比例不会固定为 96%，因为还要计算：

Sol 拆解和审查任务产生的 Token；
父 Agent 向子 Agent 传递上下文的 Token；
子 Agent 返回结果的 Token；
Luna 执行失败后的重试成本；
多个 Agent 重复读取代码产生的开销。

哪些任务适合交给 Luna？

GPT-5.6 Luna 更适合目标清楚、结果容易验证的任务，例如：

修改指定文件中的明确问题；
根据已有接口补充实现；
编写或补充单元测试；
修复已经定位的 Bug；
批量替换 API 或函数名称；
处理 ESLint、TypeScript 和格式错误；
运行测试并汇总失败信息；
修改文档和代码注释。

以下任务更适合保留给 Sol：

从模糊需求中设计完整功能；
决定系统架构或数据模型；
跨多个模块排查复杂问题；
处理安全、并发和性能问题；
审查大范围重构；
判断多个技术方案之间的取舍。

创建 Luna Worker

个人通用 Agent 可以放在：

`1`	`~/.codex/agents/luna-worker.toml`

仅对当前项目生效时，建议放在项目目录：

`1`	`.codex/agents/luna-worker.toml`

推荐配置：

name = "luna_worker"
description = "负责执行边界清晰、可以通过测试或 Diff 验证的代码修改任务。"

model = "gpt-5.6-luna"
model_reasoning_effort = "high"
sandbox_mode = "workspace-write"

developer_instructions = """
你是一个专门负责执行明确代码任务的开发 Agent。

工作要求：

1. 只处理父 Agent 明确委托的任务，不自行扩大范围。
2. 开始修改前，先确认目标文件、预期行为和验证方式。
3. 优先读取与任务直接相关的文件，不扫描整个代码仓库。
4. 采用最小修改原则，不重构无关代码。
5. 不修改未被明确要求处理的配置、依赖或公共接口。
6. 修改完成后运行最相关的测试、类型检查或构建命令。
7. 如果任务信息不足、存在架构决策或影响范围不明确，停止修改并返回父 Agent。
8. 最终返回：
   - 修改了哪些文件；
   - 每项修改的原因；
   - 执行了哪些验证；
   - 测试是否通过；
   - 尚未解决的风险。
9. 不创建新的子 Agent，不继续向下委托任务。
"""

这里建议默认使用 high，而不是直接设置成 max。

简单修改使用 medium 或 high 通常更节省；只有复杂逻辑、难以复现的 Bug 或大量边界条件检查，才值得使用 max。

可直接交给 Codex 的配置提示词

请为当前 Codex 环境创建一个自定义执行 Agent。

要求：

1. 如果是个人通用配置，在 ~/.codex/agents/ 下创建 luna-worker.toml。
2. 如果当前项目已经使用 .codex 目录，则优先创建项目级配置：
   .codex/agents/luna-worker.toml。
3. Agent 名称设置为 luna_worker。
4. 模型设置为 gpt-5.6-luna。
5. model_reasoning_effort 默认设置为 high，不要直接使用 max。
6. sandbox_mode 设置为 workspace-write。
7. Agent 只负责边界明确、可通过测试或 Diff 验证的任务，例如：
   - 修改指定代码；
   - 修复已定位 Bug；
   - 补充测试；
   - 处理类型和格式错误；
   - 运行测试并汇总结果。
8. 遇到架构决策、需求不明确、跨模块影响或安全问题时，不要擅自处理，返回父 Agent 决策。
9. 禁止该 Agent 再创建子 Agent。
10. 创建完成后：
    - 输出文件完整路径；
    - 检查 TOML 语法；
    - 显示完整配置内容；
    - 使用 git diff -- .codex/agents/luna-worker.toml 展示 Diff；
    - 如果文件位于用户主目录而不在 Git 仓库中，则使用适合当前系统的命令展示新旧差异；
    - 不要修改其他文件。

如何调用这个 Agent？

配置完成后，可以在 Codex 中明确要求分工：

先由主 Agent 分析问题、确定修改方案和验收条件。

方案确定后，将边界清晰的代码修改交给 luna_worker 执行。

luna_worker 完成后，主 Agent 必须检查 Diff、测试结果和潜在回归风险。

不要让 luna_worker 负责架构决策，也不要让多个 Agent 重复扫描整个仓库。

针对具体任务，可以这样写：

请先分析这个 Bug 的根因，不要立即修改代码。

确认根因后，把最小修复任务交给 luna_worker：
- 只修改与该 Bug 直接相关的文件；
- 补充回归测试；
- 运行相关测试；
- 返回修改摘要和测试结果。

最后由主 Agent 审查 Diff，确认没有扩大修改范围。

使用时需要注意

1. 不要把所有任务都开到 Max

更高的推理强度会消耗更多 Token。推荐按任务分级：

简单替换、格式修复：medium
常规代码修改、补测试：high
复杂逻辑和难复现问题：max

2. 不要让多个 Agent 重复读取整个项目

多 Agent 不一定天然省 Token。

如果 Sol 和 Luna 都重新扫描整个仓库，可能出现上下文重复、工具调用增加和 Token 反而上升的问题。

应由 Sol 提供明确范围：

`1`	`只检查 src/auth/session.ts 和 tests/session.test.ts`

而不是：

`1`	`检查整个项目并修复登录问题`

3. 必须设置验收条件

委托任务时至少说明：

修改目标；
允许修改的文件；
不允许修改的范围；
需要运行的测试；
什么结果算完成。

任务越明确，Luna 的成功率越高，也越不容易因为反复重试浪费 Token。

最终结论

“Sol 负责规划和审查，Luna 负责执行”的 Codex 工作流是可行的，也有官方自定义 Subagent 配置支持。

它真正节省的不是 Token 数量本身，而是把大量执行阶段的 Token 从高费率模型转移到低费率模型。

不过，不建议固定使用 Luna Max。更实用的配置是：

Sol：复杂分析、架构决策、最终审查
Terra：代码探索、较复杂的辅助分析
Luna Medium/High：明确修改、测试和批量任务
Luna Max：少量复杂但范围明确的任务

这样比“Sol + Luna Max 处理所有执行任务”更稳定，也更容易控制实际 credits 消耗。

Windows AI 工具反复报错？安装 PowerShell 7，减少无效重试和 Token 浪费

Sun, 02 Aug 2026 22:02:00 +0800

在 Windows 上使用 Codex、Claude Code、Cursor 或其他 AI 编程工具时，你可能遇到过这种情况：

执行命令
→ PowerShell 报错
→ AI 修改命令
→ 再次报错
→ AI 继续猜测和重试

每次重新读取错误、分析原因和修改命令，都会额外消耗 Token。

这并不一定是 AI 能力有问题。其中一个常见原因是：AI Agent 生成的命令与当前 PowerShell 版本或终端环境不兼容。

Windows 10 和 Windows 11 通常仍然自带 Windows PowerShell 5.1，而不少现代开发工具和 AI Agent 更适合在 PowerShell 7 中运行。

注意：安装 PowerShell 7 不能解决所有命令错误，但可以减少一部分由 PowerShell 版本、命令参数和运行环境不一致引起的无效重试。

一、检查当前 PowerShell 版本

在 PowerShell 中运行：

`1`	`$PSVersionTable`

重点查看：

1
2

PSVersion
PSEdition

如果显示类似下面的内容：

1
2

PSVersion  5.1
PSEdition  Desktop

说明当前窗口运行的是系统自带的 Windows PowerShell 5.1。

二、使用 WinGet 安装 PowerShell 7

以管理员身份打开 PowerShell，然后运行：

`1`	`winget install --id Microsoft.PowerShell --source winget`

安装过程中，WinGet 会自动下载并安装适合当前系统的 PowerShell 7。

如果提示已经安装，可以执行升级命令：

`1`	`winget upgrade --id Microsoft.PowerShell --source winget`

三、为什么安装后仍然显示 PowerShell 5.1？

PowerShell 7 不会覆盖 Windows PowerShell 5.1。

两者的启动程序不同：

版本	启动程序
Windows PowerShell 5.1	`powershell.exe`
PowerShell 7	`pwsh.exe`

因此，安装完成后继续在原来的窗口运行：

`1`	`$PSVersionTable`

可能仍然显示 5.1，这是正常现象，并不代表安装失败。

请关闭原来的终端窗口，重新打开终端，然后执行：

pwsh

再次检查版本：

`1`	`$PSVersionTable`

正常情况下会看到：

1
2

PSVersion  7.x
PSEdition  Core

还可以直接检查：

`1`	`pwsh --version`

四、将 Windows Terminal 默认终端改为 PowerShell 7

只安装 PowerShell 7 还不够。为了避免以后仍然打开 Windows PowerShell 5.1，建议修改默认终端。

操作步骤：

打开 Windows Terminal。
点击顶部的下拉箭头。
进入“设置”。
找到“默认配置文件”。
选择“PowerShell”，不要选择“Windows PowerShell”。
保存设置并重新打开终端。

注意区分：

1
2

PowerShell           → 通常是 PowerShell 7
Windows PowerShell   → 系统自带的 PowerShell 5.1

五、让 VS Code 默认使用 PowerShell 7

在 VS Code 中按下：

`1`	`Ctrl + Shift + P`

搜索并选择：

`1`	`Terminal: Select Default Profile`

然后选择：

`1`	`PowerShell`

重新创建终端：

`1`	`Terminal: Create New Terminal`

在新终端中运行：

`1`	`$PSVersionTable`

确认当前版本已经是 PowerShell 7。

六、让 AI Agent 明确调用 PowerShell 7

有些 AI 工具不会自动使用 Windows Terminal 的默认配置，而是直接调用系统里的 powershell.exe。

这时可以在 AI 工具的终端或 Shell 设置中，将执行程序改为：

`1`	`pwsh.exe`

PowerShell 7 的常见安装路径是：

`1`	`C:\Program Files\PowerShell\7\pwsh.exe`

也可以在终端中查找实际路径：

`1`	`Get-Command pwsh`

如果 AI 工具支持项目规则或长期指令，可以加入：

`1`	`在 Windows 环境执行终端命令时，优先使用 PowerShell 7（pwsh），不要默认调用 Windows PowerShell 5.1（powershell.exe）。`

七、快速验证是否配置成功

运行以下命令：

`1`	`pwsh --version`

然后运行：

`1`	`$PSVersionTable.PSVersion`

再检查程序路径：

`1`	`Get-Command pwsh`

只要能够正常显示 PowerShell 7 的版本号和安装路径，说明安装基本完成。

常见问题

安装 PowerShell 7 后，可以删除 PowerShell 5.1 吗？

不建议。

PowerShell 7 与 Windows PowerShell 5.1 可以同时存在。部分旧版 Windows 管理模块和脚本仍可能依赖 PowerShell 5.1。

为什么 AI 工具仍然调用 PowerShell 5.1？

常见原因包括：

AI 工具固定调用了 powershell.exe；
VS Code 默认终端尚未修改；
安装后没有重新启动终端；
AI 工具保留了旧的终端会话；
Shell 配置仍然指向 Windows PowerShell。

应在对应工具中明确选择 pwsh.exe。

安装 PowerShell 7 就一定能减少 Token 消耗吗？

不能保证。

它主要减少因旧版 PowerShell、命令参数或终端环境不一致造成的报错和重复尝试。权限不足、路径错误、依赖缺失、网络异常和代码本身的问题，仍然需要单独排查。

总结

对于经常在 Windows 上使用 AI 编程工具的人，推荐完成下面三项设置：

1
2
3

安装 PowerShell 7
→ 将默认终端改为 PowerShell 7
→ 确认 AI Agent 调用的是 pwsh.exe

真正关键的不是“电脑里装了 PowerShell 7”，而是AI 工具实际执行命令时使用了 PowerShell 7。

正确配置终端环境，可以减少部分无意义的报错、猜测和重复执行，也能避免 Token 浪费在本可提前解决的兼容性问题上。

PowerShell 官方项目

GitHub：PowerShell/PowerShell
Windows 安装文档：在 Windows 上安装 PowerShell

How to 怒省 Token，代码爽到飞起！马尾辫 Ponytail 实测

Fri, 31 Jul 2026 12:38:00 +0800

最近“马尾辫” Ponytail 在 GitHub 火得有点离谱，短时间内拿下超过 9.2 万 Stars。

它不是新的 AI 编程模型，而是一套可以加载到 Claude Code、Codex、Cursor、Copilot 等工具中的编程规则。它的目标很简单：

能复用就不重写，能用原生功能就不安装依赖，只编写真正需要的代码。

Ponytail 能省多少代码和 Token？

根据项目公布的新版 Agent 测试结果，Ponytail 在 12 个真实开发任务中的平均表现为：

代码量减少约 54%
Token 消耗减少约 22%
API 成本降低约 20%
任务耗时缩短约 27%
安全检查保留率为 100%

在特别容易“过度开发”的任务中，代码缩减幅度最高可以达到 94%。

例如：

开发任务	普通 AI Agent	使用 Ponytail
日期选择器	404 行	23 行
颜色选择器	287 行	23 行

原因并不复杂。

普通 AI Agent 可能会安装组件库、编写封装组件、添加样式文件，再处理一堆额外配置。Ponytail 则会先判断浏览器是否已经提供原生功能：

`1`	`<input type="date">`

能用一行解决，就不写四百行。

Ponytail 的核心不是“代码压缩”

Ponytail 并不是单纯要求 AI 少写几行代码，而是让 AI 在动手前依次判断：

这个功能真的需要吗？
项目中是否已有可复用代码？
标准库能否完成？
浏览器或系统是否自带？
已安装的依赖能否解决？
能否用一行代码完成？
都不行时，再编写最小可用实现。

它不会为了减少代码而删除数据验证、错误处理、安全检查或无障碍支持。

所以它更像一位有经验的高级程序员：不是偷懒不干活，而是不做没有必要的活。

如何安装 Ponytail？

不同 AI 编程工具的安装方法并不完全相同，不能简单理解为“把 GitHub 地址发给 IDE 就一定能自动安装”。

Claude Code

分别执行下面两条命令：

`1`	`/plugin marketplace add DietrichGebert/ponytail`

`1`	`/plugin install ponytail@ponytail`

Codex

1
2

codex plugin marketplace add DietrichGebert/ponytail
codex plugin add ponytail@ponytail

安装后重新启动 Codex，并检查插件 Hook 权限。

Gemini CLI

`1`	`gemini extensions install https://github.com/DietrichGebert/ponytail`

Cursor、Windsurf 和 Copilot Chat

这类工具通常需要从仓库复制对应的规则文件：

Cursor：.cursor/rules/
Windsurf：.windsurf/rules/
Copilot Chat：.github/copilot-instructions.md
通用 Agent：AGENTS.md

建议先阅读项目安装说明，根据自己使用的 IDE 选择对应方式。

哪些场景最适合使用？

Ponytail 比较适合：

AI 经常重复造轮子的项目
前端组件被过度封装的项目
依赖数量越来越多的代码库
Claude Code、Codex 或 Cursor 使用频率较高的开发者
希望降低 API Token 成本的个人开发者

已经足够精简的代码，使用后变化可能很小。项目测试也明确说明，94% 并不是所有任务都能达到的固定节省比例。

使用前需要注意

建议先在测试分支或小型项目中试用，并重点检查：

业务逻辑是否完整
输入验证是否保留
安全检查是否被误删
无障碍功能是否正常
原生组件是否满足设计需求

少写代码是手段，不是最终目标。真正值得追求的是：用更少的代码，稳定地完成同一件事。

GitHub 项目

Ponytail：让 AI Agent 优先复用现有能力，减少不必要代码

项目采用 MIT License。GitHub Stars、测试结果和支持的工具可能随版本更新，请以项目仓库最新说明为准。

AI 编程如何减少 Token 消耗：覆盖 Agent 工作流的 7 个开源工具

Thu, 30 Jul 2026 23:03:00 +0800

使用 Claude Code、Codex、Cursor 等 AI 编程 Agent 时，Token 消耗并不只取决于模型价格。

很多成本实际上来自重复扫描代码库、读取完整文件、加载无关上下文、分析冗长日志，以及生成没有实际价值的解释。要降低 AI 编程成本，重点不是单纯更换便宜模型，而是减少进入上下文窗口的无效信息。

下面这套方案覆盖代码探索、精准定位、规则管理、语义检索、日志过滤、回复压缩和仓库打包七个环节。

1. 使用 codebase-memory-mcp 建立代码库索引

常见问题

AI Agent 每次进入项目后，都可能重新执行以下操作：

扫描目录结构
搜索函数和类
分析调用关系
判断模块之间的依赖
重新理解 API 路由和业务流程

大型项目中，这类重复探索会消耗大量输入 Token。

解决方案

codebase-memory-mcp 会通过 Tree-sitter 分析代码，并将函数、类、调用链、路由和跨服务关系整理成持久化知识图谱。Agent 后续可以直接查询代码结构，而不必反复读取大量文件。

适合场景

长期维护的代码仓库
多模块或多服务项目
经常切换 AI 编程会话
需要分析函数调用链的项目

它更接近“代码结构记忆”，不能完全代替项目决策记录和开发文档。

2. 使用 Serena 进行符号级代码定位和修改

常见问题

Agent 可能只需要修改一个函数，却先读取整个几千行文件。这样不仅浪费 Token，还容易让无关代码干扰判断。

解决方案

Serena 是一个面向 AI 编程 Agent 的 MCP 工具包，可以按照函数、类、方法和引用关系查找代码，并进行符号级编辑、重构和调试。

例如，Agent 可以直接执行：

查找某个函数
查找函数的所有调用位置
在指定方法后插入代码
修改某个类，而不是重写整个文件

适合场景

单个文件代码较长
需要跨文件重构
希望 Agent 精确修改代码
不想让 Agent 大范围读取和重写文件

3. 使用 AGENTS.md 固化项目规则

常见问题

每次开始新会话时，都需要重复告诉 Agent：

项目使用什么技术栈
哪些目录不能修改
应该运行哪些测试
代码采用什么命名规范
修改完成后如何验证
不要生成哪些无关内容

这些重复提示不仅浪费时间，也会增加输入 Token。

解决方案

在项目根目录创建 AGENTS.md，将长期有效的项目规则统一写进去。

AGENTS.md 不是独立软件，而是一种面向编程 Agent 的开放指令格式，可以理解为“写给 AI Agent 的 README”。

# AGENTS.md

## 项目技术栈

- Python 3.12
- FastAPI
- SQLite
- Playwright

## 修改规则

- 修改前先定位相关函数，不要扫描整个仓库
- 不要修改 `vendor/` 和生成文件
- 优先复用已有组件和工具函数
- 不要添加需求之外的功能
- 不要输出大段原理说明

## 验证命令

- 运行测试：`pytest`
- 运行类型检查：`mypy app`
- 修改前端后检查移动端布局

建议只写稳定、明确、可以执行的规则。内容过长反而会让每次请求都携带更多上下文。

4. 使用 grepai 搜索任务相关代码

常见问题

传统的 grep 只能根据关键词搜索。

例如搜索“用户登录流程”时，实际函数可能叫 validateCredentials、createSession 或 verifyToken。Agent 为了找到这些代码，可能需要搜索多个关键词并逐个读取文件。

解决方案

grepai 是一个语义代码搜索工具，可以根据代码含义查找相关函数，并支持调用方、被调用方和依赖关系追踪。

1
2

grepai search "用户登录和身份验证流程"
grepai trace callers "Login"

它不会直接压缩整个上下文，而是帮助 Agent 更快找到与任务真正相关的代码，减少无效文件读取。

适合场景

不清楚功能代码位于哪个目录
项目命名不统一
需要理解完整业务流程
只想把相关代码交给 AI

5. 使用 RTK 过滤终端和日志输出

常见问题

AI Agent 执行测试、Git、Docker 或构建命令时，终端可能返回数千行内容，其中真正有价值的只有：

一条错误信息
一个失败的测试
几行调用栈
少量警告

这些原始输出会直接占用上下文窗口，并在后续对话中持续消耗 Token。

解决方案

RTK 是一个命令行代理工具，会压缩常见开发命令的输出，隐藏成功日志、进度条和重复信息，只保留错误、摘要和关键结果。

项目 README 宣称，在部分常见开发命令中可减少 60%～90% 的输出 Token，但实际效果取决于命令类型和日志内容。

适合场景

测试输出很长
Docker 日志较多
Git diff 内容庞大
构建工具输出大量成功信息

RTK 主要减少的是工具返回给 Agent 的内容，并不能解决代码检索产生的 Token 浪费。

6. 使用 Caveman 压缩 Agent 最终回复

常见问题

代码修改完成后，Agent 经常继续输出：

重复描述用户需求
大段修改原理
不必要的客套话
多种用户没有要求的备选方案
冗长的下一步建议

这些内容通常不会提高代码质量，却会增加输出 Token。

解决方案

Caveman 是一个面向 Claude Code、Codex、Cursor、Gemini CLI 等工具的 Skill 或插件，用更短的表达保留错误信息、命令和关键结论。

普通回复：

`1`	`我已经完成了相关修改。主要问题是组件在每次渲染时都会创建新的对象引用，因此建议使用 useMemo 对对象进行缓存。`

压缩后：

`1`	每次渲染都会创建新对象引用。使用 `useMemo` 缓存。

需要注意，Caveman 主要压缩输出 Token，不会自动减少 Agent 读取的代码和上下文。项目维护者也说明，在原本已经很简短的任务中，额外 Skill 指令可能无法带来明显节省。

7. 使用 Repomix 打包和过滤代码仓库

常见问题

直接将整个项目上传给 ChatGPT、Claude 或其他 AI，通常会同时包含：

依赖目录
构建产物
缓存文件
测试快照
大型日志
无关文档
可能泄露的配置和密钥

这些内容既浪费 Token，也会增加信息泄露风险。

解决方案

Repomix 可以将代码仓库整理成一个适合 AI 阅读的文件，同时支持：

按规则排除目录和文件
自动遵守 .gitignore
统计各文件 Token 数量
检查潜在敏感信息
使用 Tree-sitter 提取主要代码结构

`1`	`npx repomix@latest`

只保留函数、类和关键结构：

`1`	`npx repomix@latest --compress`

Repomix 的 --compress 模式主要保留函数和类的签名，减少实现细节，因此更适合架构分析和初步定位，不一定适合需要逐行排查的复杂 Bug。

总结

AI 编程中的 Token 优化不能只靠一句“回答简洁一点”。

真正有效的方法是分别处理不同来源的浪费：

Token 浪费来源	对应方案
重复探索代码结构	codebase-memory-mcp
读取和修改完整文件	Serena
重复输入项目规则	AGENTS.md
搜索大量无关代码	grepai
终端和测试日志过长	RTK
Agent 最终回复冗长	Caveman
上传整个代码仓库	Repomix

这些工具的功能存在一定重叠，也会带来安装、索引和维护成本。正确做法不是全部堆上，而是先观察 Token 主要浪费在哪个环节，再选择对应工具。

GitHub 项目地址

codebase-memory-mcp https://github.com/DeusData/codebase-memory-mcp
Serena https://github.com/oraios/serena
AGENTS.md https://github.com/agentsmd/agents.md
grepai https://github.com/yoanbernabeu/grepai
RTK https://github.com/rtk-ai/rtk
Caveman https://github.com/JuliusBrussee/caveman
Repomix https://github.com/yamadashy/repomix

AI 换图常用提示词：将产品自然融入新场景

Thu, 30 Jul 2026 22:54:00 +0800

使用 AI 进行产品换背景或场景合成时，常见问题包括产品变形、材质改变、比例错误、光影不一致，以及产品与背景之间出现明显的“粘贴感”。

下面这套提示词适合杯子、鞋子、包装盒、化妆品、电子产品等商品换场景任务。

通用提示词

将图1中的【杯子】精准提取并放入图2的场景中。

严格保持杯子的原始造型、尺寸比例、轮廓结构、材质、颜色、纹理、图案、文字、Logo和所有产品细节不变，不得重新设计、简化或改变产品外观。

根据图2的场景环境，重新匹配杯子的摆放位置、透视角度、空间比例、拍摄视角和景深关系，使杯子符合场景中的真实空间结构。

分析图2的主光方向、光源高度、光线软硬、综合色温、环境亮度、对比度和饱和度，并为杯子重新生成与场景一致的自然高光、明暗过渡、接触阴影、环境反射和真实投影。

正确处理杯子与桌面、背景及周围物体之间的遮挡、接触和前后关系，修复不自然的边缘、悬浮、穿模、重叠、光影断层和视觉接缝。

最终效果应像杯子原本就在图2场景中完成实景拍摄，产品主体清晰，边缘自然，光影统一，空间关系真实，无明显抠图痕迹或AI合成感。

可替换变量

将提示词中的内容替换为自己的产品：

`1`	`【杯子】→ 鞋子、香水瓶、手提包、包装盒、服装、食品、电子产品`

还可以补充具体摆放要求：

将产品放在画面右侧桌面区域。
保持产品正面朝向镜头。
产品占画面高度约35%。
不要遮挡产品Logo和包装文字。
保持图2原有背景构图不变。

强化产品一致性的限制词

当 AI 容易修改产品外观时，可追加以下内容：

禁止改变产品造型，禁止修改颜色，禁止改变材质，禁止重绘Logo，禁止生成错误文字，禁止增加或删除零件，禁止改变产品比例，禁止表面纹理丢失，禁止边缘融化，禁止产品变形，禁止悬浮，禁止不合理阴影，禁止双重投影，禁止背景结构变化。

电商产品图版本

将图1中的【产品】完整放入图2场景，产品本身必须保持高度一致，包括外形、颜色、材质、表面纹理、包装文字、Logo、接口、配件和细节位置。

保持图2原有构图和环境不变，只调整产品的透视、尺寸、位置、光照和投影。产品边缘清晰自然，主体完整可见，不被无关物体遮挡。

根据场景生成真实的接触阴影、环境反射和高光变化，使产品看起来是在该场景中真实拍摄，而不是后期粘贴。整体达到商业电商摄影效果，画面干净、真实、清晰，无AI变形和文字错误。

使用建议

图1尽量选择产品轮廓完整、细节清晰、无遮挡的图片。
图2需要预留足够的产品摆放空间。
明确产品位置、大小和朝向，比只说“放进去”更稳定。
包含文字或Logo的产品，应反复强调“文字和Logo不得改变”。
第一次生成后，可继续要求AI只修复阴影、比例或边缘，不要重新生成整张图片。

Awesome GPT Image 2 Prompts：GitHub 开源 AI 绘图提示词库

Thu, 30 Jul 2026 22:16:00 +0800

不会写 AI 绘图提示词，可以先从现成案例开始修改。

GitHub 上的开源项目 Awesome GPT Image 2 Prompts，整理了 462 个 GPT Image 2 图像生成与编辑案例。每个案例通常包含效果预览、完整提示词和原始创作者信息，适合用来查找灵感或学习提示词结构。

项目收录了哪些内容？

提示词主要覆盖以下商业设计场景：

电商产品主图与产品广告
品牌海报与营销素材
人像摄影与时尚大片
App UI 和网页界面
角色设定与三视图
社交媒体配图
信息图与电影感视觉
图片编辑与风格转换

相比从零编写提示词，这类案例库最大的价值是：你可以先找到接近目标的画面，再修改其中的产品、颜色、背景、构图和文字要求。

如何使用这些提示词？

1. 找到接近需求的案例

例如需要制作饮料海报，可以搜索：

drink poster
beverage advertisement
product photography
scrapbook poster

需要设计网页或 App 界面，可以搜索：

UI mockup
landing page
mobile app
dashboard

2. 复制提示词并替换变量

例如项目中的“蓝莓薰衣草苏打剪贴簿海报”，可以重点替换：

产品：蓝莓薰衣草苏打
口味：蓝莓、薰衣草、奶油泡沫
配色：紫色、蓝色、奶油白
风格：复古剪贴簿、咖啡店广告
画幅：4:5、4:3 或 1:1

修改成自己的产品后，再补充品牌名称、目标用户、使用场景和需要展示的文字。

3. 根据生成结果继续调整

提示词不是复制后就一定能得到完全相同的图片。模型版本、参考图片、画幅比例和生成次数都会影响结果。

第一次生成后，可以继续提出具体修改：

保持产品外观不变，将背景改为浅紫色。
减少装饰元素，让产品成为视觉中心。
修正海报文字，确保品牌名称拼写正确。
将画面调整为 4:3 横版网站封面。

相比重新生成整张图片，这种逐步修改通常更容易获得稳定结果。

这个项目适合谁？

普通用户可以直接修改现成提示词，快速制作封面图、产品图和社交媒体素材。

设计师与运营人员可以把它当作视觉参考库，研究不同商业场景中的构图、灯光、材质和排版表达。

开发者可以参考项目中的提示词结构，将 GPT Image 2 接入批量生成图片、广告素材或内容管理工作流。

使用时需要注意

项目中的提示词可以作为创作参考，但最终效果仍需要人工检查，特别是：

品牌名称和海报文字是否正确
产品结构是否发生变化
人物手指和局部细节是否异常
是否包含未经授权的商标或人物形象
生成内容是否符合所用平台的商业使用规则

好的提示词不是堆砌“8K、电影级、高级感”等形容词，而是清楚说明主体、场景、构图、材质、灯光、文字和禁止出现的内容。

GitHub 项目

项目名称：Awesome GPT Image 2 Prompts

GitHub：

https://github.com/Evolink-AI/awesome-gpt-image-2-API-and-Prompts

项目采用 CC0-1.0 许可，但使用具体案例、品牌元素或生成图片时，仍建议检查原始来源、模型服务条款和相关版权要求。

AI 漫剧制作 Skill 工作流：用剧本、资产和分镜提高创作效率

Wed, 29 Jul 2026 11:47:00 +0800

制作 AI 漫剧，真正困难的通常不是生成一张图片，而是如何让剧情节奏、人物形象和镜头衔接保持一致。

目前 GitHub 上已经出现多套面向 Claude Code、Codex 等 AI Agent 的开源 Skills。虽然不同项目的命名并不完全相同，但核心流程基本可以归纳为三类：

剧本创作 Skill
图像资产 Skill
分镜制作 Skill

这三类 Skill 可以把小说或创意逐步转换为剧本、角色资产、分镜表和图像或视频提示词。

一、剧本创作 Skill

剧本 Skill 负责把小说、故事大纲或简单创意，整理成适合短剧和漫剧制作的结构化剧本。

常见输出包括：

故事背景与核心冲突
角色身份、动机和人物关系
分集大纲
场景编号与场景说明
人物动作和对白
每集开头的吸引点
结尾悬念或下一集钩子

它的价值不是单纯“把文字写长”，而是提前解决剧情节奏问题。

很多 AI 漫剧画面并不差，但播放数据不理想，常见原因是开头进入剧情太慢、冲突不明确，或者每集结尾缺少继续观看的理由。

因此，剧本生成后仍然需要人工检查：

前几秒是否出现核心事件
主角目标是否明确
冲突是否能够通过画面表现
对白是否过多
每个场景是否有存在的必要

二、图像资产 Skill

图像资产 Skill 会从剧本中提取需要反复使用的视觉元素，例如：

主要角色
次要角色
服装造型
场景
道具
交通工具
特殊物品
关键视觉符号

随后，它会为每项资产生成结构化说明和图像提示词。

一份实用的角色资产档案，至少应包含：

年龄范围
脸型与五官特征
发型和发色
身材与体态
服装款式、颜色和材质
常用表情
正面、侧面和背面参考
中文与英文提示词
不允许变化的角色特征

这一步的重点是解决**角色一致性**。

同一个人物在不同镜头中出现时，应尽量复用相同的角色描述和参考图，而不是每次重新生成一套提示词。否则容易出现脸型、发型、服装颜色和年龄不断变化的问题。

三、专业分镜 Skill

分镜 Skill 负责把剧本转换成可以直接执行的镜头清单。

它通常会为每个镜头标注：

镜头编号
场景与时间
出场人物
景别
摄影机角度
人物位置
人物动作
表情变化
灯光与色调
镜头运动
台词或旁白
建议时长
首帧或关键帧提示词

例如，剧本中只有一句：

主角发现桌上的合同被人替换。

分镜需要进一步明确：

先用近景展示主角翻开合同
再切换到合同签名位置的特写
主角手指停顿，表情从疑惑变为警觉
镜头缓慢推进
背景声音逐渐减弱
最后切到门外模糊的人影

只有完成这样的镜头拆解，图像模型和视频模型才能获得更明确的执行信息。

三类 Skill 如何组成完整工作流

一套基础的 AI 漫剧生产流程可以按照下面的顺序执行：

第一步：导入故事

输入小说章节、故事大纲或原创创意，明确：

视频类型
目标平台
单集时长
画面比例
目标观众
视觉风格

第二步：生成分集剧本

使用剧本 Skill 输出分集大纲和单集剧本，并人工确认剧情逻辑、冲突和结尾钩子。

第三步：建立资产库

使用资产 Skill 提取角色、场景和道具，先生成角色参考图或三视图。

资产确认后再进入批量分镜阶段，避免后期不断返工。

第四步：生成分镜

使用分镜 Skill 将剧本拆解为逐镜头表格，并生成每个镜头的关键帧提示词。

第五步：生成图片和视频

把已经确认的角色参考图、场景资产和分镜提示词交给图像或视频模型。

生成过程中应优先检查：

人物是否一致
服装是否变化
场景空间是否连续
人物动作能否衔接
镜头景别是否过于重复

使用 Skill 不代表可以完全自动化

Skill 的作用是把经验和制作规则整理成可重复执行的流程，但它不能自动保证作品质量。

实际制作中仍然需要人工完成：

判断故事是否值得制作
修改生硬对白
选择最终角色形象
检查人物和场景一致性
筛选生成结果
控制节奏、配音和音乐
处理版权及人物肖像风险

更准确地说，Skill 能够减少重复整理和提示词编写工作，让创作者把更多时间放在剧情判断和成片质量上。

总结

AI 漫剧制作的关键，不是一次生成多少张图片，而是能否建立稳定的生产流程。

剧本 Skill 负责解决故事和节奏问题，资产 Skill 负责保持人物与场景一致，分镜 Skill 负责把文字转换为可执行的镜头。

将这三类 Skill 串联起来，可以明显减少重复工作，但最终作品是否好看，仍然取决于创作者对剧情、画面和节奏的判断。

一句话克隆网站：AI Agent 像素级复刻工具

Wed, 29 Jul 2026 10:37:00 +0800

想快速复刻一个网站的页面设计，又不想从零手写 React 组件和 CSS？

AI Website Cloner Template 提供了一套基于 AI Agent 的网站逆向工程流程：输入目标网址并运行 /clone-website，AI 会分析页面、提取设计规范、下载素材，并生成结构清晰的 Next.js 项目。

它并不是简单的“截图转 HTML”，而是把网站拆解为可维护的 React 组件、Tailwind CSS 样式、TypeScript 类型和本地素材文件，适合网站迁移、旧站重建、源码找回和前端学习。

这个工具能做什么？

它主要解决的是“从现有网站视觉效果到可编辑前端代码”的问题。

自动截取桌面端和移动端页面
提取颜色、字体、间距、圆角、阴影等设计 Token
分析滚动、悬停、点击、弹窗和轮播等交互
下载图片、视频、字体、SVG 和网站图标
按页面区块生成 React 组件规格
并行生成 Next.js 组件
对比原站与复刻页面，进行视觉 QA
输出可继续修改和部署的前端项目

核心工作流程

1. 页面侦察

AI Agent 通过浏览器自动化工具打开目标网站，滚动并检查完整页面，同时记录桌面端、移动端和不同交互状态。

2. 提取设计规范

工具会读取页面的实际样式，包括：

字体名称、字号和字重
颜色和渐变
内外边距
圆角、边框和阴影
响应式断点
动画时间和缓动方式

这些数据会被整理为 Tailwind CSS 和全局样式中的设计 Token，减少凭感觉猜测样式的问题。

3. 下载真实素材

页面中的图片、视频、字体、SVG、favicon 和 Open Graph 图片会被保存到本地项目中。

这意味着生成结果使用的是目标页面的真实素材，而不是由 AI 临时生成的占位内容。

4. 生成组件规格

AI 会按照导航栏、首屏、功能区、案例区、价格区和页脚等页面区块，生成详细的组件规格文档。

规格中会记录：

组件结构
文本内容
精确样式值
素材路径
交互状态
响应式表现

5. 并行生成代码

不同区块可以交给多个 AI Agent 并行处理，最终合并为完整页面。

生成项目主要使用：

Next.js
React
TypeScript
Tailwind CSS
shadcn/ui

6. 视觉 QA

页面生成后，AI 会再次运行网站并截图，与原页面进行视觉对比，检查布局、字体、颜色、间距和素材是否存在明显偏差。

生成后的项目结构

src/
├─ app/                 # Next.js 路由与页面
├─ components/          # 页面 React 组件
│  ├─ ui/               # shadcn/ui 基础组件
│  └─ icons.tsx         # 提取的 SVG 图标
├─ hooks/               # 自定义 React Hooks
├─ lib/                 # 公共工具
└─ types/               # TypeScript 类型

public/
├─ images/              # 下载的图片
├─ videos/              # 下载的视频
└─ seo/                 # favicon、OG 图片等

docs/
├─ research/            # 页面分析与组件规格
└─ design-references/   # 原网站截图

如何使用？

准备条件

使用前需要准备：

Node.js 24 或更高版本
一个支持该项目的 AI 编程工具
可用的浏览器自动化能力，例如 Chrome MCP、Playwright MCP 或 Puppeteer MCP

项目推荐使用 Claude Code，同时也支持 Codex CLI、Cursor、Gemini CLI、GitHub Copilot、Windsurf、Cline、Roo Code 等工具。

第一步：创建自己的项目

打开 GitHub 项目页面，点击 Use this template，再选择 Create a new repository。

不要直接把官方模板仓库当成自己的网站项目提交修改。

第二步：克隆自己的仓库

1
2
3

git clone https://github.com/你的用户名/你的仓库名.git
cd 你的仓库名
npm install

第三步：启动 AI Agent

以 Claude Code 为例：

`1`	`claude --chrome`

第四步：运行网站克隆命令

`1`	`/clone-website https://example.com`

也可以一次提供多个网址：

`1`	`/clone-website https://example.com https://example.com/pricing`

第五步：运行项目

`1`	`npm run dev`

完成后访问本地开发地址，检查页面并继续修改内容、品牌信息和业务逻辑。

它适合哪些场景？

适合

将自己的网站迁移到 Next.js
旧网站只有线上页面，但源码已经丢失
将 WordPress、Webflow 或 Squarespace 页面重建为现代前端项目
学习优秀网站的布局、动效和响应式设计
快速搭建内部原型或页面改版基础
在获得授权后重建客户网站

不适合

自动还原原网站的后端数据库
复制登录、支付、会员和实时业务系统
自动修复原网站不合理的业务逻辑
把别人的品牌、文案和设计冒充为自己的作品
制作钓鱼网站或仿冒登录页面
绕过目标网站的服务条款、版权或访问限制

使用前必须知道的限制

“像素级复刻”是一项目标，而不是任何网站都能百分之百实现的保证。

以下内容通常仍需要人工调整：

复杂的 WebGL、Canvas 或 3D 动画
登录后才能访问的页面
依赖后端接口的动态数据
个性化推荐和实时内容
支付、账号、权限和数据库逻辑
受跨域、反爬虫或访问权限保护的素材
原网站未公开的源代码与内部实现

生成完成后，开发者仍然需要进行代码 Review、性能优化、无障碍检查、SEO 配置和业务改造。

一句话总结

AI Website Cloner Template 更像一个“网站视觉逆向工程助手”，而不是自动重构完整业务系统的万能工具。

它可以显著缩短页面搭建时间，并把目标网站的视觉结构转换为可继续开发的 Next.js 代码；但后端功能、版权合规、性能优化和真实业务逻辑，仍然需要开发者自己完成。

GitHub 项目

项目名称：AI Website Cloner Template
GitHub：JCodesMore/ai-website-cloner-template
开源协议：MIT

请只复刻自己拥有、已经获得授权，或明确允许研究和重建的网站。不要将该工具用于仿冒、钓鱼、侵权或其他违法用途。

如何用 ChatGPT Images 控制目标布局、图案和配色

Tue, 28 Jul 2026 20:06:00 +0800

很多人使用 ChatGPT Images 时，会把大量精力放在描述“画面要多精美”，却没有明确说明元素放在哪里、图案如何保留、颜色如何分配。

想让生成结果更接近目标图，关键不是不断堆叠风格词，而是把提示词拆成三个可控制部分：

布局约束
图案约束
配色约束

ChatGPT Images 支持根据文字生成图片，也可以结合上传的参考图片继续编辑和调整。参考图越清晰、每张图片的用途说明越明确，最终结果通常越稳定。

一、先准备三类参考素材

不要只上传一张图片，然后让 AI 同时猜测布局、图案和颜色。

更稳定的方法是分别准备：

布局参考图：用于确定元素位置、留白和视觉重心。
图案参考图：用于保留纹理、花型、材质或产品细节。
配色参考图：用于确定主色、辅助色和点缀色。

上传后，需要明确告诉 ChatGPT 每张图片的作用。

参考图 1：只参考整体布局和元素位置。

参考图 2：只参考图案、纹理和材质细节，不要改变图案比例。

参考图 3：只提取配色，不参考其中的物体和构图。

这种写法可以避免模型把不同参考图中的元素混合在一起。

二、使用结构化提示词

一个容易控制的 ChatGPT Images 提示词，可以按照下面的顺序编写：

图片用途
画面比例
布局结构
主体内容
图案要求
配色要求
材质与光线
文字内容
禁止出现的内容

不要把所有要求写成一段没有层级的长句。

三、如何准确控制布局

“画面高级、构图大气、视觉丰富”这类描述过于抽象，无法告诉 AI 元素应该放在哪里。

可以改成更具体的位置关系：

生成一张 4:3 横版网站封面图。

画面采用左右分栏布局：

左侧约占画面 55%，放置主要视觉主体；
右侧约占画面 45%，放置配色卡、图案参考和界面元素。

标题位于左上区域，距离边缘保留充足安全留白。
主体位于左侧中下方，不要遮挡标题。
右侧信息按垂直方向整齐排列。

需要进一步控制时，可以加入网格、占比和对齐方式：

使用三栏网格布局。
主要主体占两栏，辅助元素占一栏。
所有元素沿同一条水平基线对齐。
画面四周保留约 8% 的安全边距。

四、如何保留目标图案

只写“使用参考图中的图案”通常不够。

需要说明哪些部分必须保持一致：

严格保留参考图中的图案结构、方向和密度。

不要重新设计花型。
不要放大或缩小图案比例。
不要改变图案之间的间距。
不要增加参考图中不存在的装饰。

用于面料、包装或产品设计时，可以进一步补充：

图案需要自然贴合物体表面，并随褶皱和透视产生合理变形。

图案不能悬浮在物体表面。
不能出现断裂、错位、重复边界或镜像拼接。

五、如何准确控制配色

“使用蓝色”“采用高级配色”仍然不够具体。

建议把颜色分成三个层级：

1
2
3

主色：深蓝色，占画面约 70%。
辅助色：浅灰色，占画面约 20%。
点缀色：暖橙色，占画面约 10%。

也可以直接提供十六进制颜色：

主背景色：#101827
辅助界面色：#D9E2EC
重点强调色：#FF9F43

不要出现紫色渐变、荧光绿色和高饱和粉色。

明确颜色比例，可以减少 AI 自动加入无关颜色的问题。

六、不要一次要求 AI 完成所有细节

复杂图片建议分三轮生成。

第一轮：只确认布局

1
2
3

先生成低细节构图草案。

这一轮只确认元素位置、大小关系、留白和视觉层级，不需要增加复杂纹理。

第二轮：锁定图案和配色

保持当前布局不变。

将主体图案替换为参考图 2 中的图案，并严格使用指定配色。
不要移动任何主要元素。

第三轮：处理材质、文字和细节

保持现有布局、图案和颜色不变。

增强材质细节、光影层次和边缘清晰度。
修正标题文字，不要修改其他区域。

这种分阶段修改的方法，比每次重新生成整张图片更容易保持一致。ChatGPT Images 也支持在现有图片基础上继续编辑，并尽量保留未修改区域。

七、可直接复制的通用提示词

请结合我上传的参考图片，生成一张可用于网站首页的视觉素材。


网站首页封面图，用于介绍 ChatGPT Images 的布局、图案和配色控制方法。


4:3 横版构图，适合网站首页展示。
画面四周保留安全留白，不要裁切标题和主体。


参考图 1：只参考布局和元素位置。
参考图 2：只参考图案、纹理和材质。
参考图 3：只参考配色。

不要把三张参考图中的物体随意混合。


采用左右分栏构图。
左侧约占 55%，放置主要视觉主体和标题。
右侧约占 45%，展示布局网格、图案样本和配色卡。
视觉重心位于画面中部偏左。


严格保留参考图中的图案结构、方向、比例和密度。
不要重新设计图案。
不要增加新的纹样。
避免图案断裂、错位、镜像和不自然重复。


主色使用深蓝灰色，占画面约 70%。
辅助色使用浅灰白色，占画面约 20%。
点缀色使用橙色，占画面约 10%。
不要出现紫色渐变和无关的高饱和颜色。


现代数字创意工作台风格。
界面清晰，结构专业，细节精致。
使用柔和体积光、磨砂玻璃和轻微金属质感。
不要过度炫光，不要堆叠无意义的科技元素。


主标题：ChatGPT Images 视觉控制指南
副标题：布局 · 图案 · 配色

确保文字完整、清晰、没有错别字。


不要出现人物。
不要出现品牌 Logo。
不要增加无关英文。
不要改变画面比例。
不要让辅助元素遮挡标题。

八、常见问题

生成结果与参考图差距很大

通常是因为没有说明每张参考图的用途。应分别标注哪些图片控制布局、图案和颜色。

图案被 AI 重新设计

在提示词中加入“严格保留图案结构、方向、比例和密度”，并明确禁止新增纹样。

颜色总是发生偏移

提供具体色值和颜色占比，同时列出禁止出现的颜色。

修改文字后整张图片都变了

要求 AI 只修改指定区域，并强调：

`1`	`除标题文字外，保持其他区域完全不变。`

画面比例不正确

不要只写“横版图片”，应明确写出：

`1`	`4:3 横版构图，最终尺寸为 1200 × 900 像素。`

总结

使用 ChatGPT Images 生成可控视觉素材时，可以记住一个简单公式：

参考图分工
+ 布局位置
+ 图案约束
+ 颜色比例
+ 分阶段修改

提示词越具体，AI 需要猜测的内容越少。

真正有效的提示词不是堆叠“高级、震撼、电影感”等形容词，而是明确告诉模型：什么必须保留、什么可以调整，以及每个元素应该出现在哪里。

官方资料与 GitHub 项目

OpenAI Cookbook 图片生成提示词指南： https://github.com/openai/openai-cookbook/blob/main/examples/multimodal/image-gen-models-prompting-guide.ipynb
OpenAI 图片生成示例项目： https://github.com/openai/openai-imagegen-demo
OpenAI Cookbook： https://github.com/openai/openai-cookbook

Codex + Obsidian 长期记忆配置：让 AI 跨项目记住工作进度和关键决策

Tue, 28 Jul 2026 19:42:00 +0800

Codex 每次开始新任务时，最麻烦的问题之一，就是需要重新解释项目背景、工作习惯和之前做过的决定。

解决这个问题的一种方法，是把 Obsidian 作为 Codex 的外部长期记忆库，将项目规划、关键决策、工作流程和每日复盘记录保存在本地 Markdown 文件中。

需要说明的是，这种方案并不是给 Codex 增加真正意义上的“永久大脑”，而是建立一套：

任务前读取历史信息，任务后更新工作记录的本地记忆工作流。

目前 Codex 已经提供本地 Memories 功能，相关文件默认保存在 ~/.codex/memories/，并可通过 /memories 控制当前对话是否读取或生成记忆。Obsidian 方案的价值，则在于记忆内容更加透明、可编辑、可分类，也更方便跨项目和跨工具使用。

一、Codex + Obsidian 的工作原理

整个流程可以分为四步：

在 Obsidian 中建立固定的记忆库目录。
使用 AGENTS.md 告诉 Codex 应该读取哪些笔记。
每次任务开始前，读取相关项目状态和历史决策。
任务完成后，将结果、问题和下一步计划写回 Obsidian。

Codex 会在执行任务前读取 AGENTS.md。你既可以在 ~/.codex/AGENTS.md 中设置全局规则，也可以在具体项目目录中添加项目级规则。

二、推荐的 Obsidian 记忆库结构

可以在 Obsidian Vault 中建立下面的目录：

Codex-Memory/
├── 00_INDEX.md
├── 01_GOALS/
│   └── long-term-goals.md
├── 02_PROJECTS/
│   ├── website.md
│   └── automation.md
├── 03_DECISIONS/
│   └── decision-log.md
├── 04_WORKFLOWS/
│   └── working-rules.md
├── 05_PREFERENCES/
│   └── user-preferences.md
└── 06_DAILY/
    └── 2026-07-28.md

各目录可以分别保存：

00_INDEX.md：记忆库入口和目录说明。
01_GOALS：长期目标和当前重点。
02_PROJECTS：不同项目的背景、进度和待办事项。
03_DECISIONS：重要选择、原因和最终结论。
04_WORKFLOWS：代码规范、发布流程和操作步骤。
05_PREFERENCES：常用格式、表达习惯和工具偏好。
06_DAILY：每日任务总结和复盘记录。

不要让 Codex 每次读取整个 Obsidian 仓库。更合理的方式是先读取索引，再根据当前任务加载相关笔记，这样可以减少无关上下文和 Token 消耗。

三、配置 Codex 的 AGENTS.md

在全局 Codex 目录或项目根目录中创建：

`1`	`AGENTS.md`

Windows 用户通常可以放在：

`1`	`C:\Users\你的用户名\.codex\AGENTS.md`

示例内容：

# Codex 长期记忆规则

## Obsidian 记忆库

记忆库路径：

D:\Obsidian\Codex-Memory

## 开始任务前

1. 首先读取 `00_INDEX.md`。
2. 根据当前任务判断所属项目。
3. 读取对应的 `02_PROJECTS` 项目文件。
4. 检查 `03_DECISIONS` 中是否存在相关历史决策。
5. 只读取与当前任务直接相关的笔记，不要扫描整个仓库。

## 完成任务后

1. 更新对应的项目状态。
2. 将重要决策写入 `03_DECISIONS/decision-log.md`。
3. 将当天完成内容写入 `06_DAILY/YYYY-MM-DD.md`。
4. 记录遇到的问题、解决方案和下一步计划。
5. 不要保存密码、API Key、Cookie 或其他敏感信息。

## 记忆写入原则

只保存未来仍然有价值的信息，包括：

- 长期目标
- 项目背景
- 技术选择
- 关键决策及原因
- 可复用工作流程
- 用户明确表达的长期偏好

不要保存临时聊天、重复内容和一次性任务信息。

四、设置每日复盘

仅在 AGENTS.md 中写入“每天凌晨复盘”，并不会让 Codex自动执行。

要实现定时复盘，还需要使用：

Windows 任务计划程序
Linux 或 macOS 的 Cron
支持定时任务的 AI Agent
已经包含夜间整理功能的 Obsidian AI 项目

每天执行的复盘任务可以使用下面的提示词：

读取今天的项目记录和每日笔记。

请完成以下工作：

1. 总结今天完成的主要任务。
2. 提取值得长期保存的关键决策。
3. 更新对应项目的当前状态。
4. 合并重复或已经失效的信息。
5. 将复盘结果写入今天的每日笔记。
6. 不要写入密码、Token、Cookie 或其他敏感数据。

部分开源项目已经实现了夜间整理、索引更新和跨项目记忆功能，但不同项目的自动化程度并不相同。例如，codex-obsidian-memory-loop 明确定位为手动复盘工作流，而不是后台自动监控系统。

五、原生 Codex Memory 与 Obsidian 的区别

方案	主要特点	适合场景
Codex 原生 Memories	自动从历史对话生成本地记忆	希望简单开启、减少手动维护
Obsidian 记忆库	内容透明、可编辑、可分类	项目管理、知识沉淀、跨工具复用
AGENTS.md	固定 Codex 的读取和执行规则	编码规范、项目流程、记忆读取入口
定时复盘脚本	自动整理每日记录	长期项目和持续知识维护

更实用的方式不是二选一，而是组合使用：

使用 Codex Memories 保存自动生成的上下文。
使用 Obsidian 保存经过确认的重要知识。
使用 AGENTS.md 定义读取和写回规则。
使用定时任务完成每日整理。

六、使用时需要注意的问题

不要保存敏感信息

不要把下面的信息写入记忆库：

API Key
登录密码
Cookie
私钥
客户隐私资料
未脱敏的内部数据

Codex 官方也建议在共享 Codex 目录或记忆文件前检查其中是否包含敏感内容。

不要无限追加笔记

记忆库并不是越大越好。

如果所有对话和日志都永久保存，Codex 检索时反而更容易读到过期信息。建议定期执行：

删除重复记录
标记失效决策
合并相似笔记
更新项目当前状态
保留决策发生的时间和原因

重要操作仍需人工确认

Codex 可以参考历史记录，但涉及删除文件、修改生产环境、付款、发布和权限调整时，仍然应该由用户最终确认。

七、适合使用这套方案的人

这套 Codex + Obsidian 长期记忆工作流，比较适合：

同时维护多个代码项目的开发者
经常使用 Codex 处理重复任务的人
希望沉淀项目决策和踩坑记录的个人用户
使用多个 AI 编程工具的团队
希望将 Obsidian 打造成 AI 第二大脑的人

它真正解决的问题，不是让 Codex 永远记住所有聊天，而是让重要信息以本地文件的形式保存下来，并在需要时被准确读取。

AI 反推提示词教程：3 步从参考图片生成可复用的生图提示词

Tue, 28 Jul 2026 17:21:00 +0800

看到一张喜欢的图片，却不知道应该怎样写提示词？

可以使用“AI 反推提示词”工作流，让支持图片识别的 AI 先分析画面，再将分析结果整理成适合 Midjourney、Stable Diffusion、即梦、豆包或其他生图工具使用的提示词。

整个流程分为三个步骤：

拆解图片元素
生成基础提示词
优化成指定工具可直接使用的版本

需要注意的是，AI 反推得到的通常不是原作者输入的真实提示词，而是根据图片内容推测出的近似描述。它更适合用来学习画面的构图、风格、光影和视觉语言，而不是逐字恢复原始 Prompt。

第一步：拆解图片元素

先把参考图片上传给支持图片识别的 AI，例如 ChatGPT、Gemini、Claude 或其他多模态模型。

不要一开始就让 AI 直接生成提示词，而是先要求它对图片进行结构化拆解。

可直接复制的指令

请详细拆解这张图片，并按照以下维度进行分析：

1. 主体：画面中的主要人物、物体或视觉对象。
2. 场景：主体所处的环境、时间、地点和空间关系。
3. 动作：人物姿态、表情、动作方向，以及物体的运动状态。
4. 风格：写实摄影、商业广告、插画、动漫、3D渲染、赛博朋克或其他视觉风格。
5. 色调：主色、辅助色、色彩饱和度、冷暖关系和整体情绪。
6. 光线：光源方向、光线强弱、自然光或人工光，以及阴影和高光表现。
7. 构图：景别、拍摄角度、主体位置、视觉中心、前景、中景和背景关系。
8. 材质：皮肤、布料、金属、玻璃、木材或其他表面的纹理表现。
9. 镜头：可能使用的焦段、景深、透视关系和摄影机位。
10. 细节：画面中的道具、装饰、环境元素和容易被忽略的信息。

请尽量描述具体，不要只使用“高级感”“电影感”“氛围感”等空泛词语。
最后将分析结果整理成结构化列表。

为什么需要先拆解

直接让 AI 反推提示词，常见结果是：

`1`	`一个女孩站在街道上，电影感，高清，细节丰富。`

这种描述虽然没有错，但缺少人物姿态、服装材质、环境光线、镜头角度和构图关系，很难稳定复现参考图片的视觉效果。

先拆解图片，可以减少遗漏，也方便后续修改其中某一个元素。

第二步：反向生成基础提示词

完成图片拆解后，再让 AI 把分析结果组合成完整的生图提示词。

可直接复制的指令

请根据刚才的图片分析结果，反向生成一套完整的AI生图提示词。

要求：

1. 保留主体、场景、动作、构图、色调、光线、材质和镜头信息。
2. 使用具体、可视化的描述，不要只写“高级感”“震撼”“精美”等抽象词。
3. 按照以下顺序组织：
   主体 → 动作 → 场景 → 构图 → 光线 → 色彩 → 材质 → 风格 → 镜头 → 画质。
4. 不要添加原图中不存在的人物、物体、文字或装饰。
5. 分别输出中文提示词和英文提示词。
6. 额外提供一组负面提示词，用于避免文字、水印、变形、模糊和多余元素。

目标是尽可能还原参考图片的视觉氛围、构图方式和画面质感，而不是猜测原作者输入过的真实提示词。

第三步：优化成指定 AI 工具版本

不同 AI 生图工具对提示词的理解方式并不完全相同。

因此，基础提示词生成后，还需要告诉 AI 你准备使用哪一个生图工具。

通用优化指令

请将刚才的提示词优化成适合【工具名称】直接使用的版本。

要求：

1. 保留原图最重要的主体、构图、色调、光线和材质特征。
2. 调整语序和表达方式，使其符合该工具的提示词习惯。
3. 删除重复、矛盾和无法被模型理解的描述。
4. 不要随意改变原图内容。
5. 如果该工具支持参数，请补充合理参数。
6. 如果该工具不支持某项参数，请不要虚构。
7. 最终只输出：
   - 成品提示词
   - 负面提示词
   - 参数说明

提示词需要能够直接复制使用。

将其中的“工具名称”替换为：

Midjourney
Stable Diffusion
Flux
即梦AI
豆包
通义万相
Gemini
ChatGPT图像生成

Midjourney 提示词优化指令

请将这套图片描述优化成适合 Midjourney 使用的英文提示词。

要求：

1. 使用自然、连贯的英文视觉描述。
2. 优先描述主体、场景、构图、光线、色彩和镜头。
3. 删除重复词和没有实际视觉意义的形容词。
4. 不要添加原图中不存在的元素。
5. 根据参考图比例添加合适的 --ar 参数。
6. 根据画面需要添加合理的 --stylize 参数。
7. 最终只输出一条可以直接复制到 Midjourney 使用的完整提示词。

示例：

A realistic photograph of a white lighthouse standing on a rocky coastline at sunset, a small red-roofed house beside it, ocean waves crashing against dark rocks, warm golden sunlight passing through orange and pink clouds, rule-of-thirds composition, foreground rocks creating leading lines, wide-angle lens, natural cinematic lighting, realistic textures, high dynamic range, detailed coastal atmosphere --ar 4:3 --stylize 150

Stable Diffusion 提示词优化指令

请将这套图片描述优化成适合 Stable Diffusion 或 Flux 使用的提示词。

请分别输出：

1. Positive Prompt
2. Negative Prompt
3. 推荐画面比例
4. 推荐采样步数
5. 推荐 CFG 范围

要求：

- 主体描述放在前面。
- 使用清晰、具体的视觉关键词。
- 避免重复堆砌 masterpiece、best quality 等质量词。
- 负面提示词重点排除文字、水印、模糊、畸形和多余主体。
- 参数只提供通用建议，不要声称所有模型都使用相同设置。

通用负面提示词示例：

`1`	`low quality, blurry, distorted perspective, malformed objects, duplicated subjects, extra limbs, bad anatomy, oversaturated colors, text, watermark, logo, frame, compression artifacts`

让反推结果更准确的补充指令

第一次生成的提示词不够准确时，可以继续让 AI 对比和修正。

请重新检查参考图片和刚才生成的提示词，找出提示词中遗漏、描述错误或权重不足的部分。

重点检查：

1. 主体位置是否准确。
2. 人物或物体数量是否正确。
3. 拍摄角度和景别是否一致。
4. 光源方向是否正确。
5. 主色调和冷暖关系是否准确。
6. 前景、中景和背景是否完整。
7. 是否加入了原图中不存在的元素。

请根据检查结果重新输出一版更准确、更简洁的提示词。

一个更高效的一次性提示词

不想分三次操作，也可以使用下面这套完整指令：

请根据我上传的参考图片，完成一次AI生图提示词反向分析。

第一步，详细分析图片中的主体、场景、人物动作、视觉风格、色调、光线、构图、材质、镜头和关键细节。

第二步，根据分析结果生成一套能够尽量还原原图视觉效果的中文和英文提示词。

第三步，将提示词优化成适合【工具名称】直接使用的版本，并补充负面提示词与必要参数。

要求：

- 使用具体、可视化的描述。
- 不要只使用“高级感”“电影感”“精美”等空泛词语。
- 不要添加原图中不存在的内容。
- 清楚区分图片中能够确认的信息和根据画面推测的信息。
- 不要声称能够恢复原作者的真实提示词。
- 最终结果必须可以直接复制使用。

使用时需要注意的三个问题

1. AI 无法保证恢复原始提示词

同一张图片可以由多套不同提示词生成。反推提示词的本质，是根据最终画面重新描述视觉信息，而不是读取图片背后的原始 Prompt。

2. 图片中的文字需要单独处理

AI 对招牌、海报、包装和界面文字的识别可能出现错误。涉及准确文字时，应手动提供文字内容，不要完全依赖图片反推。

3. 参数不能机械照搬

采样器、步数、CFG、模型版本和 LoRA 权重主要适用于 Stable Diffusion 类工具。Midjourney、Gemini、ChatGPT 图像生成和即梦等平台使用不同的控制方式，不应强行套用相同参数。

适用场景

这套 AI 反推提示词工作流适合用于：

分析优秀摄影作品的构图和光线
学习商业海报的视觉结构
复刻相近的插画或 3D 风格
提取网站 Banner 的画面语言
优化产品图和电商主图提示词
将参考图片转换成 Midjourney 或 Stable Diffusion Prompt
建立个人 AI 图片提示词素材库

建议把反推得到的内容当作初始版本，再根据实际生成结果不断调整主体、构图和光线，而不是一次生成后直接结束。

Cheat on Content：用 AI 预测视频表现，让内容创作从直觉走向数据

Tue, 28 Jul 2026 16:14:00 +0800

做短视频时，最难判断的往往不是“能不能写出来”，而是：

这个选题值得拍吗？
标题有没有吸引力？
发布后可能获得多少播放？
为什么有些视频表现很好，有些却没有流量？

Cheat on Content 是一个开源的 AI 内容分析工具。它不会承诺准确预测某条视频一定能获得多少播放量，而是帮助创作者建立一套可以持续校准的内容评估系统。

它的核心思路是：

创作稿件
→ 发布前打分
→ 记录预测结果
→ 发布内容
→ 回收真实数据
→ 分析预测偏差
→ 更新评分规则

随着历史样本不断增加，这套系统会越来越了解你的账号，而不是只依赖通用的爆款公式。

Cheat on Content 能做什么？

1. 发布前评估内容潜力

将视频脚本或文章草稿交给 AI 后，它会根据当前评分规则，对内容进行分析，例如：

选题是否符合目标受众
开头是否能够留住用户
标题是否具有点击吸引力
内容结构是否清晰
评论区是否有讨论空间
可能出现哪些传播风险

这些分数不是平台官方预测数据，而是基于历史样本和自定义规则得出的参考结果。

2. 记录发布前预测

工具会在内容发布前保存预测结果，包括：

预估播放量区间
预期互动表现
内容优势
潜在问题
预测依据

发布后再将真实数据导入，避免出现“看到结果后再解释原因”的事后分析。

3. 根据真实数据复盘

视频发布一段时间后，可以录入实际播放量、点赞、评论、收藏等数据。

系统会对比：

1
2
3

发布前预测结果
VS
发布后的真实表现

然后找出预测偏高或偏低的原因，帮助创作者判断：

是选题判断错误
是标题不够准确
是开头留存不足
还是账号受众与预期不同

4. 持续更新评分规则

当系统连续多次出现同一方向的预测偏差时，会提示调整评分规则。

新规则不会直接覆盖旧规则，而是需要重新测试历史样本。只有新规则对过去内容的判断更加准确，才适合继续使用。

这让内容评估从一次性的 AI 建议，变成一套能够持续迭代的创作系统。

如何使用 Cheat on Content？

第一步：初始化内容项目

安装完成后，在 Claude Code 或 Codex 中输入：

`1`	`初始化 cheat-on-content`

工具会询问内容类型、更新频率、账号方向等基础信息，并在项目目录中创建所需文件。

第二步：导入历史内容

建议准备至少 5～10 条历史内容作为初始样本，包括：

表现较好的视频
表现一般的视频
表现较差的视频
对应的标题或文字稿
播放量、点赞、评论等数据

不要只导入爆款内容。

只有同时提供成功和失败样本，AI 才能识别两者之间真正有价值的差异。

第三步：分析新稿件

将准备发布的视频脚本保存到项目中，然后让工具进行打分和预测。

例如：

`1`	`打分这篇 scripts/video-001.md`

或：

`1`	`启动预测 scripts/video-001.md`

AI 会分析稿件并给出修改建议，同时保存发布前预测。

第四步：发布并记录结果

内容发布后，将真实数据录入系统。

工具会把实际结果与原始预测进行对比，并生成复盘记录。

第五步：升级内容评分规则

当历史样本逐渐增加后，系统会根据预测偏差建议更新评分标准。

长期使用后，你会得到一套更符合自己账号、赛道和受众的内容判断方法。

这个工具适合哪些人？

Cheat on Content 比较适合：

短视频创作者
自媒体运营人员
知识类博主
YouTube、抖音、小红书内容团队
需要批量测试选题的企业账号
使用 Claude Code 或 Codex 创作内容的人

它尤其适合已经发布过一批内容，但仍然无法总结流量规律的创作者。

使用时需要注意什么？

预测结果不是流量保证

视频播放量还会受到发布时间、平台推荐、账号权重、热点变化、封面、剪辑质量等因素影响。

因此，预测分数更适合用于比较多个选题，而不是把某个数字当成最终结果。

初期预测误差可能较大

项目说明中提到，如果没有导入历史对标样本，前几篇内容的预测误差可能较明显。

使用时间越长、样本越完整，评分规则才越有参考价值。

数据整理需要一定时间

目前使用过程中，仍需要手动整理脚本和发布数据。

对于完全不熟悉终端、Markdown 或 Claude Code 的用户，初次配置会有一定学习成本。

总结

Cheat on Content 的价值，并不是神奇地算出一条视频能获得多少播放量。

它真正解决的问题是：

将“我感觉这个选题可能会火”，变成一套有记录、有预测、有结果、有复盘的内容实验流程。

对于长期做短视频或自媒体的人来说，单次 AI 改稿并不难，真正困难的是建立稳定的判断标准。

Cheat on Content 提供了一种可执行的方法，让每次发布都能为下一次创作积累数据。

GitHub 项目地址

Cheat on Content - GitHub

Claude Code 安装

1
2
3

git clone https://github.com/XBuilderLAB/cheat-on-content.git
cd cheat-on-content
bash install.sh

Codex 安装

1
2
3

git clone https://github.com/XBuilderLAB/cheat-on-content.git
cd cheat-on-content
bash install.sh --codex

安装完成后，建议重新打开 Claude Code 或 Codex 会话，再执行初始化命令。

AI 复刻爆款视频提示词模板：逐镜头拆解并生成视频提示词

Tue, 28 Jul 2026 16:02:00 +0800

看到一条节奏、运镜或视觉效果出色的视频，如何让 AI 帮助我们学习它的制作方法？

比较实用的方式，不是让 AI 简单描述“视频里有什么”，而是要求它按照时间顺序进行逐镜头拆解，分析人物动作、摄影机运动、光线、构图、节奏和转场，再将分析结果整理成适用于 AI 视频生成模型的提示词。

这种方法更适合用于：

分析短视频的镜头节奏
学习广告片的视觉表达
提取电影感运镜方法
生成多镜头视频提示词
优化 Seedance、Kling、Veo、Sora、Runway 等模型的输入内容

重点是学习镜头逻辑和视觉方法，而不是直接复制原视频中的人物、品牌、台词或受版权保护的创意内容。

一、这套提示词解决什么问题？

普通的 AI 视频分析通常只会输出：

画面中出现了什么
人物做了什么
视频大概是什么风格

这些信息不足以重新制作一条结构完整的视频。

真正影响生成效果的内容还包括：

每个镜头持续多长时间
人物动作如何开始和结束
摄影机从哪里移动到哪里
前后镜头如何衔接
主体位置和背景关系
光线方向与材质表现
角色、服装和场景如何保持一致
环境音、动作音效和音乐节奏如何配合

因此，需要让 AI 同时担任视频提示词架构师、电影镜头分析师和多模态视频逆向工程师。

二、可直接复制的完整提示词

你现在是一名专业的视频提示词架构师、电影级镜头语言分析师和多模态视频逆向工程师。

我会向你提供一段参考视频。你的任务不是简单概括视频内容，也不是照搬其中的人物、品牌、台词或受版权保护的创意，而是分析它使用的镜头逻辑、动作设计、视觉结构和节奏方法，并将其转化为一套可用于 AI 视频生成模型的原创提示词。

请严格按照以下步骤执行。

# 第一阶段：视频基础识别

首先识别并说明：

1. 视频总时长
2. 画面比例
3. 视频类型
4. 核心主体
5. 主要场景
6. 整体视觉风格
7. 色彩倾向
8. 剪辑节奏
9. 可能使用的生成或拍摄方法
10. 视频最值得学习的镜头设计

# 第二阶段：逐镜头拆解

按照时间顺序拆分视频，不要遗漏明显的镜头变化。

每个镜头需要分析以下内容：

- 时间范围
- 镜头时长
- 主体身份与外观
- 人物服装
- 人物动作轨迹
- 表情与视线变化
- 主体与道具的互动
- 场景空间关系
- 前景、中景和背景
- 景别
- 摄影机机位
- 拍摄角度
- 推测焦段
- 景深
- 构图方式
- 摄影机运动
- 运镜方向
- 运镜速度
- 光源方向
- 光线软硬
- 色温
- 材质与表面反射
- 画面色彩
- 特效
- 环境声音
- 动作音效
- 音乐节奏
- 转场方式
- 镜头结束时的画面状态

请使用以下格式输出：

## 镜头 01

- 时间范围：
- 镜头时长：
- 画面内容：
- 主体外观：
- 人物动作：
- 表情与视线：
- 场景与空间：
- 景别与机位：
- 镜头焦段：
- 构图方式：
- 摄影机运动：
- 光线与色彩：
- 材质表现：
- 声音设计：
- 结束画面：
- 镜头衔接：

# 第三阶段：提取可复用的视觉方法

完成逐镜头分析后，总结视频中可以迁移到其他原创内容中的方法，包括：

1. 开场如何吸引注意力
2. 主体如何进入画面
3. 动作高潮如何设计
4. 运镜如何配合人物动作
5. 不同镜头如何保持方向连续
6. 如何利用前景、中景和背景建立空间感
7. 如何通过光线和材质提升质感
8. 如何控制镜头节奏
9. 如何设计结尾画面
10. 哪些元素属于通用方法，哪些元素不应直接复制

# 第四阶段：生成原创视频方案

根据以上分析，设计一套保留相似镜头方法、但主体、场景和内容均为原创的新视频方案。

请先输出：

- 原创视频主题
- 主体设定
- 角色外观设定
- 服装设定
- 场景设定
- 道具设定
- 光线设定
- 色彩设定
- 视频时长
- 镜头数量
- 整体节奏
- 声音设计

# 第五阶段：生成成品视频提示词

将原创视频方案转换为适用于 AI 视频生成模型的分镜提示词。

每个镜头必须使用以下结构：

[镜头编号]

[镜头时长]
明确镜头持续时间。

[人物与主体]
描述人物身份、年龄范围、外观、发型、服装、道具以及需要保持一致的特征。

[人物动作]
按照时间顺序描述人物动作，避免在一个镜头中安排过多复杂动作。

[摄影机运动]
明确景别、机位、拍摄角度、焦段、运动方向、运动速度和稳定方式。

[场景与构图]
描述主体位置、前景、中景、背景、空间关系和构图方式。

[光线与材质]
描述光源方向、光线软硬、色温、阴影、材质、反射和环境氛围。

[结束画面]
明确镜头最后一帧的人物姿态、主体位置、摄影机位置和画面状态。

[镜头衔接]
说明如何连接下一镜头，例如直接切换、动作匹配剪辑、遮挡转场、运动方向匹配或声音提前进入。

[声音]
描述环境音、动作音效、对白、旁白或音乐节奏。

# 第六阶段：一致性限制词

在每个镜头末尾加入与当前镜头相关的稳定性要求，并在整套提示词末尾加入全局限制词。

全局限制词参考：

保持同一人物身份、面部特征、发型、年龄、体型和肤色一致；
保持服装款式、颜色、材质和配饰一致；
保持场景结构、背景物体位置和光线方向一致；
人物动作连续自然，运动轨迹清晰；
保持正确的人体比例和关节结构；
双手结构自然，手指数目正确；
无多余肢体，无肢体融合，无关节扭曲；
无面部变形，无身份切换，无五官漂移；
无服装变色，无服装漂移，无纹理闪烁；
无背景闪烁，无物体随机出现或消失；
无画面跳帧，无动作断裂，无速度突变；
保持真实重力、碰撞、惯性和物体接触关系；
人物与道具之间不存在穿透、漂浮或错误遮挡；
镜头运动平滑稳定，不产生无意义抖动；
保持曝光、白平衡、色彩和景深连续；
避免字幕、文字、水印、品牌标志和界面元素；
避免低清晰度、过度锐化、塑料质感和明显 AI 伪影。

可以同时生成一份适合模型使用的英文限制词：

consistent character identity, stable facial features, same hairstyle, same body proportions, consistent clothing and accessories, no face morphing, no identity change, no outfit change, no clothing flicker, correct anatomy, natural hands, correct fingers, no extra limbs, no fused limbs, no twisted joints, stable background, no background flicker, no object popping, continuous motion, smooth action trajectory, no frame skipping, no sudden speed change, realistic gravity, realistic collision, correct object interaction, no penetration, no floating objects, consistent lighting, consistent exposure, stable camera movement, no watermark, no subtitles, no logo, no visual artifacts

# 第七阶段：最终输出格式

请依次输出：

1. 视频整体分析
2. 逐镜头拆解表
3. 可复用的镜头方法
4. 原创视频方案
5. 中文成品提示词
6. 英文成品提示词
7. 全局限制词
8. 生成时可能出现的问题
9. 针对问题的二次优化建议

如果无法确认某项镜头参数，请明确标注“推测”，不要将推测内容写成确定事实。

三、成品镜头提示词格式

实际生成视频时，可以把每个镜头单独整理成下面的结构：

[镜头编号] Shot 01

[镜头时长]
4 秒。

[人物与主体]
一名穿深灰色夹克的年轻男性站在雨后的城市街道上。保持人物面部、短发、身材比例、服装颜色和材质在所有镜头中一致。

[人物动作]
人物先低头看向手中的金属装置，随后缓慢抬头，将视线转向画面右侧。动作连续自然，不出现突然转身。

[摄影机运动]
中近景，略低机位，50mm 镜头。摄影机从人物正前方缓慢向前推进，运动平滑稳定。

[场景与构图]
人物位于画面左侧三分线。前景有轻微虚化的雨滴，中景为人物，背景为带有散景灯光的城市街道。

[光线与材质]
右后方冷色轮廓光，左前方柔和暖色补光。夹克表面呈现轻微湿润反光，金属装置具有真实高光和细小划痕。

[结束画面]
人物抬头看向画面右侧，摄影机停在中近景位置，背景灯光保持稳定。

[镜头衔接]
通过人物视线方向直接切换至下一镜头，下一镜头主体从画面右侧出现。

[声音]
轻微雨声、远处车辆声、衣料摩擦声和低频悬念音乐。

[限制词]
保持人物身份与服装一致，无面部变形，无服装漂移，无背景闪烁，无肢体错误，动作连续，摄影机运动平滑，物理关系真实。

四、使用方法

将参考视频上传给支持视频理解的 AI。
复制完整提示词并发送。
让 AI 先完成逐镜头分析，不要立即生成最终提示词。
检查镜头数量、人物动作和时间轴是否正确。
要求 AI 将参考内容改写为原创主体和原创场景。
根据使用的模型，调整镜头时长和提示词长度。
最好逐镜头生成，再通过剪辑软件完成拼接。
人物一致性要求较高时，应同时使用角色参考图、首帧图或上一镜头结束帧。

五、为什么要逐镜头生成？

一次性要求 AI 生成包含大量动作和多次转场的长视频，容易出现：

人物突然变脸
服装颜色改变
动作前后不连续
背景物体随机变化
摄影机方向混乱
多个人物位置互换
道具穿过人物身体
结尾画面无法衔接下一镜头

将视频拆成多个独立镜头，可以更准确地控制动作、构图、运镜和角色一致性。

生成完成后，再利用剪辑软件按照时间顺序拼接，通常比直接生成一整段长视频更稳定。

六、需要注意的版权问题

这套方法适合分析和学习：

镜头运动
构图方式
光线设计
剪辑节奏
动作组织
视觉叙事方法

不建议直接复制：

原视频中的人物肖像
品牌标志和产品设计
原创角色形象
完整台词和旁白
具有明确识别度的剧情
受版权保护的音乐和画面

更合理的做法是保留镜头方法，重新设计人物、场景、动作和故事内容。

七、相关 GitHub 资源

目前没有找到与本文这套中文模板完全对应的唯一开源项目，但以下项目和资料可用于学习 AI 视频提示词结构：

Video-As-Prompt https://github.com/bytedance/Video-As-Prompt
HunyuanVideo 1.5 Prompt Handbook https://github.com/Tencent-Hunyuan/HunyuanVideo-1.5
Seedance 2 Prompt Library https://github.com/gracech0322-cmd/seedance-2-prompt-library

这些项目与本文模板并非同一个项目，主要作为视频提示词、镜头控制和视频生成方法的延伸参考。

AI Skills 入门教程：用一个 SKILLs.md，让 AI 记住你的工作方法

Tue, 28 Jul 2026 15:54:00 +0800

每次让 AI 写周报、整理会议纪要或分析数据，都要重新解释格式、语气和步骤？

这类问题可以通过 AI Skills 解决。

Skills 可以理解为写给 AI 的一份“标准操作手册”：它把任务说明、执行规则、参考案例和所需资源整理在一个文件夹中。当用户提出相关需求时，支持 Agent Skills 的 AI 工具可以读取并执行这些规则。

简单来说：普通提示词只服务于当前对话，Skills 更适合保存可重复使用的工作流程。

Skills 是什么？

一个 Skills 通常对应一项明确任务，例如：

根据工作记录生成周报
按固定标准审核文章
整理会议纪要并提取待办事项
检查代码中的安全问题
按品牌规范生成营销文案

官方 Agent Skills 规范将 Skills 定义为一种轻量级开放格式。最基础的 Skills 是一个文件夹，其中必须包含 Skills.md；复杂 Skills 还可以附带脚本、模板、示例和参考资料。

Skills 能解决什么问题？

1. 减少重复沟通

不需要每次都重新说明：

输出包含哪些栏目
使用什么语气
哪些内容不能出现
数据应该如何展示
最终结果采用什么格式

2. 统一输出标准

多人或多次使用同一个 Skills 时，可以尽量保持相同的结构、流程和判断标准。

3. 沉淀个人工作方法

当你发现一套提示词效果很好，可以把它整理成 Skills，而不是让它一直留在聊天记录中。

需要注意的是，Skills 并不是让 AI 获得真正的“永久记忆”。它更像一份保存在本地或项目目录中的规则文件：只有工具能够发现并加载它时，规则才会生效。

Skills 的基本目录结构

一个标准 Skills 不只是单独散落的文本文件，而是一个独立文件夹：

weekly-report/
├── Skills.md
├── references/
│   └── report-example.md
└── templates/
    └── weekly-report-template.md

其中：

Skills.md：必需，写明名称、用途和执行规则
references/：可选，存放参考资料或优秀案例
templates/：可选，存放固定模板
scripts/：可选，存放需要执行的辅助脚本

Anthropic 和 OpenAI 的官方文档都将 Skills 描述为包含指令、资源以及可选脚本的任务能力包，而不只是一个简单提示词。

三步写出第一个 Skills

下面以“周报助手”为例。

第一步：写清楚名称和触发条件

在 Skills.md 顶部加入 YAML 元数据：

---
name: weekly-report
description: 根据用户提供的本周工作记录生成中文周报。当用户要求写周报、整理本周工作，或提交一组工作记录时使用。
---

至少应写清楚：

name：Skills 的名称
description：它能做什么，以及什么时候应该使用

description 不要只写“处理文档”或“提高效率”，否则 AI 很难判断什么时候需要调用它。

第二步：把要求改成可执行规则

不要只写：

1
2

写得专业一点。
内容简洁一些。

这种描述过于主观，不同模型可能有不同理解。

可以改成：

# 周报生成规则

收到用户的工作记录后，按以下顺序处理：

1. 将内容分为：
   - 本周完成
   - 进行中
   - 下周计划

2. 每条内容优先保留：
   - 项目名称
   - 完成数量
   - 当前进度
   - 产生的结果
   - 后续动作

3. 不得虚构用户未提供的数据。

4. 没有具体数字时，保留原始事实，并注明“未提供量化数据”。

5. 删除“积极推进”“持续赋能”“圆满完成”等空泛表达。

6. 每条控制在两句话以内。

7. 最后增加一段不超过80字的本周总结。

这些规则能够直接执行，也更容易检查结果是否合格。

第三步：提供输入与输出示例

示例能帮助 AI 理解你真正想要的效果。

# 示例

## 输入

- 完成用户调研
- 修复了几个登录页面的问题
- 数据看板还在调整
- 下周准备上线新活动

## 输出

### 本周完成

1. 完成用户调研，共收集326份有效问卷，并整理出15条核心反馈。
2. 修复登录页面3个影响用户使用的问题，登录功能已通过测试。

### 进行中

1. 数据看板重构已完成约60%，预计下周完成剩余图表和筛选功能。

### 下周计划

1. 完成数据看板重构并提交测试。
2. 上线新用户活动，持续跟踪访问量和注册转化率。

### 本周总结

本周重点完成用户调研和登录功能修复，数据看板重构按计划推进，下周将进入功能上线和数据验证阶段。

示例越接近真实工作场景，输出通常越稳定。

可直接复制的完整 Skills.md

---
name: weekly-report
description: 根据用户提供的工作记录生成结构清晰的中文周报。当用户要求写周报、总结本周工作或发送零散工作记录时使用。
---

# 周报助手

## 目标

将用户提供的零散工作记录整理为可以直接发送的中文周报。

## 执行步骤

1. 阅读全部工作记录。
2. 合并重复事项。
3. 按“本周完成、进行中、下周计划”分类。
4. 保留项目名称、数量、进度、结果和下一步动作。
5. 生成结构清晰的 Markdown 周报。

## 输出结构

### 本周完成

列出已经完成并产生结果的事项。

### 进行中

列出尚未完成的任务，并说明当前进度和下一步动作。

### 下周计划

列出下周需要执行的具体任务。

### 本周总结

使用不超过80字总结本周重点、进展和风险。

## 写作规则

- 使用平实、清晰的中文。
- 每条内容不超过两句话。
- 优先使用具体数字、进度和结果。
- 不使用“积极推进”“持续赋能”“圆满完成”等空泛表达。
- 不得编造用户没有提供的信息。
- 信息不足时，保留原意并注明缺少的数据。
- 默认使用 Markdown 格式。

## 示例

输入：

- 完成客户调研
- 修复登录页面问题
- 看板还在调整
- 下周上线活动

输出：

### 本周完成

1. 完成客户调研，并整理主要需求和反馈。
2. 完成登录页面问题修复，相关功能已恢复正常。

### 进行中

1. 数据看板仍在调整，下一步将完善图表和筛选功能。

### 下周计划

1. 完成数据看板调整并提交测试。
2. 上线新活动并跟踪用户参与数据。

### 本周总结

本周完成客户调研和登录问题修复，数据看板正在推进，下周重点为活动上线和数据验证。

新手常见的三个错误

触发条件太模糊

错误写法：

用于处理工作。

推荐写法：

`1`	`当用户要求生成周报，或提交本周工作记录时使用。`

规则只有形容词

错误写法：

`1`	`写得专业、简洁、有深度。`

推荐写法：

`1`	`正文不超过500字，每条不超过两句话，每项至少保留一个结果或进度信息。`

一个 Skills 承担太多任务

不建议把“写周报、做PPT、分析数据、发送邮件”全部放进同一个 Skills。

更合理的方式是拆成多个独立 Skills：

weekly-report/
meeting-notes/
data-analysis/
email-reply/

一个 Skills 只解决一类明确问题，通常更容易触发，也更方便维护。

使用第三方 Skills 前要注意什么？

不要看到 GitHub 上的 Skills 就直接安装。

第三方 Skills 可能附带脚本、命令或外部资源。使用前至少检查：

Skills.md 要求 AI 执行哪些操作
是否包含 scripts/ 等可执行文件
是否会读取环境变量、密钥或私人文件
是否要求上传数据到外部服务
GitHub 仓库是否持续维护

研究已经指出，Agent Skills 生态存在指令注入、恶意脚本和供应链风险，因此第三方 Skills 应当像第三方代码一样审查，而不是只把它当作文档。

去哪里找现成的 Skills？

可以从以下官方项目开始：

建议先阅读官方示例，再根据自己的工作流程修改。不要直接复制一个功能复杂的 Skills，然后期待它完全符合自己的需求。

总结

写 Skills 的关键，不是堆积大量提示词，而是把一项任务说明清楚：

什么时候使用
按什么步骤执行
必须遵守哪些规则
最终输出什么格式
什么样的结果才算合格

第一次可以从最常用、最重复的一项任务开始，例如周报、会议纪要或文章审核。先完成一个简单可用的版本，再根据实际输出逐步补充规则和示例。

DeepTutor：可本地部署的开源 AI 学习与工作伴侣

Tue, 28 Jul 2026 15:16:00 +0800

同时使用 ChatGPT、Claude、知识库、笔记软件和多个 AI Agent 时，真正影响效率的往往不是模型能力，而是分散的窗口、重复导入的资料，以及无法连续保存的上下文。

DeepTutor 是一个开源的智能学习工作区。它把对话、知识管理、书籍学习、智能体、写作、研究和长期记忆等功能整合在同一个工作空间中，减少在不同 AI 工具之间反复切换的问题。

DeepTutor 是什么？

DeepTutor 是由 HKUDS 开源的 Agent-native 个性化学习平台。

与普通 AI 聊天工具不同，DeepTutor 不只是回答问题，而是尝试把用户上传的资料、历史互动、学习进度和个人知识组织到同一个工作环境中。

官方目前提供的主要工作区包括：

对话与学习辅导
AI Partners 与自定义智能体
协作写作
书籍阅读与学习
Learning Space 学习空间
Memory 长期记忆
Knowledge Center 知识中心

这些模块共享统一的运行上下文，因此从阅读资料切换到提问、写作或练习时，不必频繁重新提交背景信息。

传统 AI 工作流常见的问题

1. 多个窗口来回切换

完成一个学习或研究任务时，可能需要同时打开：

AI 对话工具
PDF 阅读器
浏览器
笔记软件
文档编辑器
本地文件夹

工具越多，注意力越容易被界面切换打断。

2. 知识与对话无法连续积累

很多 AI 对话结束后，资料、结论和上下文仍然分散在不同会话中。

下次继续处理同一个主题时，往往还要重新上传文件、解释背景和复制之前的内容。

3. AI 只回答问题，不管理学习过程

普通聊天机器人通常更擅长完成一次性问答，但不会主动整理知识、生成练习、记录薄弱点或根据历史表现调整学习内容。

DeepTutor 希望解决的正是这个问题：让 AI 从临时问答工具，变成能够持续参与学习过程的助手。

DeepTutor 的核心功能

功能模块	主要作用
AI 对话	针对上传资料或指定主题进行提问、解释和学习辅导
知识中心	管理个人资料，并在回答中检索和引用相关内容
书籍学习	阅读长文本、整理章节、提取重点并辅助理解
个性化记忆	保存学习记录和互动信息，形成持续更新的用户画像
问题与练习生成	根据资料生成问题、测验和针对性练习
智能体系统	通过不同 Agent 分工完成研究、学习和复杂任务
协作写作	根据资料进行整理、改写和内容创作
可视化学习	通过图表、结构图等方式展示概念和知识关系

DeepTutor 的相关研究介绍了一套混合个性化机制：一部分用于连接静态知识资料，另一部分用于从持续互动中整理用户的学习状态和历史记录。

系统还会把资料问答、问题生成、难度调整和学习反馈连接起来，形成相对完整的学习闭环。

DeepTutor 适合哪些人？

DeepTutor 更适合以下使用场景：

学生和自学者

可以上传教材、论文、讲义或自己的笔记，让 AI 帮助解释概念、总结重点、生成问题和检查掌握情况。

研究人员

可以将论文和研究资料放入知识中心，用于资料检索、文献理解、多文档分析和研究写作。

内容创作者

可以利用个人资料库完成选题研究、文章整理、知识提炼和内容写作，减少反复查找资料的时间。

需要长期积累知识的工作者

咨询、产品、技术、运营和教育工作者，可以把项目资料与个人经验逐步沉淀到统一工作空间中。

DeepTutor 是否完全离线？

DeepTutor 支持本地部署，但“本地部署”并不一定等于“完全离线”。

实际的数据处理方式取决于你连接的模型和服务：

使用本地大模型和本地嵌入模型时，可以减少资料发送到第三方服务器的情况。
使用 OpenAI、Claude 或其他云端模型时，请求内容仍可能发送给对应的模型服务商。
部署前应检查模型接口、知识库、日志目录和数据存储设置。

因此，更准确的说法是：DeepTutor 提供本地部署和自行配置模型的能力，隐私程度取决于最终的部署方案，而不是安装完成后天然完全离线。

DeepTutor 的优点

开源，可以查看代码并自行部署
将学习、知识库、写作和智能体整合到统一工作区
支持持续记忆和个性化学习
适合处理书籍、文档和长期知识资料
可以连接本地模型或兼容的模型服务
支持通过 Skill 扩展智能体能力

官方仓库显示，DeepTutor 已采用 Apache-2.0 开源许可证，并在 2026 年发布了重新设计的 1.0.0 版本。

使用前需要注意的问题

DeepTutor 功能较多，因此部署和使用成本通常会高于普通 AI 聊天客户端。

使用前建议确认：

电脑是否已经安装所需的 Python、Node.js 等运行环境。
准备使用本地模型还是云端模型。
本地设备是否有足够的内存、显存和存储空间。
上传的资料是否包含敏感信息。
当前版本支持哪些模型、文件格式和知识库组件。

如果只是偶尔向 AI 提问，普通聊天工具可能更加简单。

如果你的重点是长期学习、知识积累、资料研究和个性化辅导，DeepTutor 才更能体现价值。

总结

DeepTutor 并不是简单地把多个 AI 功能放进一个界面。

它更重要的价值，是把资料、对话、记忆、学习进度和智能体能力放进同一个持续运行的工作环境中。

对于需要长期阅读、研究和整理知识的人来说，这种工作方式可以减少重复导入上下文，让 AI 从一次性问答工具逐渐变成真正能够参与学习过程的助手。

项目地址

GitHub：https://github.com/HKUDS/DeepTutor
官方网站：https://deeptutor.info/
开源许可证：Apache-2.0

两个免费开源 AI Skills：快速制作电影感项目演示视频

Tue, 28 Jul 2026 15:04:00 +0800

制作一个像样的项目演示视频，通常需要完成脚本、录屏、动画、架构图、音效和剪辑等多个步骤。

现在可以借助两个开源 AI Skills，简化其中最耗时间的两个环节：

video-shotcraft：生成电影感产品演示和项目开场动画
Archify：将代码仓库或系统描述转换成技术架构图

它们可以配合 Claude Code、Codex 等 AI 编程助手使用，比较适合开发者制作产品发布视频、GitHub 项目介绍、SaaS 功能演示和技术方案展示。

video-shotcraft：生成电影感项目演示视频

video-shotcraft 是一个面向 Claude Code 和 Codex 的 AI 视频制作 Skill。

它基于 Remotion 工作流，将项目页面、产品截图和功能素材组合成具有镜头运动、节奏切换和音效设计的演示视频。

项目内提供了：

106 个镜头设计方案
161 个动态效果预览
可直接修改的 Remotion 视频模板
页面截图与界面展示方案
2.5D 镜头移动效果
节奏同步剪辑与音效设计方法

使用时，可以让 AI 分析项目特点，生成分镜方案，再通过 Remotion 渲染为视频。

它适合制作：

GitHub 开源项目介绍
SaaS 产品发布视频
网站首页功能演示
软件更新宣传片
应用功能预告片

需要注意的是，video-shotcraft 提供的示例项目和默认模板包含作者自己的产品界面。

正式制作时，应替换以下内容：

产品截图
网站页面
项目名称
功能演示素材
配色与视觉元素
音效和背景音乐

不要直接使用默认素材，否则最终视频可能更像原项目的宣传片，而不是你自己的项目演示。

Archify：把代码仓库转换成架构图

Archify 是一个面向 Cursor、Claude Code、Codex CLI 和 OpenCode 的技术架构可视化 Skill。

你可以向它提供：

一个代码仓库
一段系统结构说明
服务之间的调用关系
产品业务流程
数据流和生命周期描述

Archify 会将这些信息整理成可交互的技术架构图。

目前支持的主要图表类型包括：

系统架构图
工作流程图
时序关系图
数据流图
生命周期图

生成结果可以导出为：

HTML
PNG
SVG
WebM
社交媒体分享图

与普通静态架构图相比，Archify 更强调结构验证、节点关系、上下游路径和架构变更对比，适合用于技术文档、项目汇报和代码评审。

注意：Archify 当前没有把“自动解析 Mermaid 代码”列为支持范围。更稳妥的方式是直接提供代码仓库或用自然语言描述系统结构。

两个 Skill 如何组合使用

可以按照下面的流程制作一条完整的项目演示视频：

分析项目
   ↓
整理核心功能和演示重点
   ↓
使用 Archify 生成项目架构图
   ↓
准备网站截图和功能录屏
   ↓
使用 video-shotcraft 设计分镜与动画
   ↓
替换默认项目素材
   ↓
通过 Remotion 渲染视频
   ↓
检查字幕、节奏、音效和项目名称

Archify 负责把项目结构讲清楚，video-shotcraft 负责把项目展示得更有电影感。

例如，一条开源项目介绍视频可以这样安排：

使用 video-shotcraft 制作项目 Logo 或首页的开场动画。
展示项目解决的问题和核心功能。
插入 Archify 生成的系统架构图。
展示真实页面截图或功能操作过程。
用简短总结说明项目适用场景。
在结尾展示 GitHub 项目地址。

安装方式

两个项目都属于命令行工具，需要先准备 Node.js、Git 和相应的 AI 编程助手。

Archify 可以使用 Skills CLI 安装：

`1`	`npx skills add tt-a1i/archify -g`

安装完成后，可以向 AI 助手输入：

`1`	`Use archify to map this repository's runtime architecture.`

video-shotcraft 可以通过仓库说明中的 Skills CLI、克隆仓库或手动链接方式安装。

对于不熟悉命令行的用户，可以直接把 GitHub 仓库地址交给 Claude Code、Codex 或其他具有终端操作能力的 AI 助手，并要求它：

1
2

请阅读这个项目的 README，检查本地环境，完成安装并运行示例。
遇到错误时先分析原因，再逐步修复，不要跳过依赖检查。

使用建议

第一次使用时，不建议直接让 AI 生成完整视频。

更稳定的流程是：

先生成视频脚本。
确认需要展示的功能。
准备真实项目截图。
单独生成架构图。
再制作分镜和动画。
最后统一渲染成片。

这样可以避免出现界面与项目无关、架构图信息错误、镜头节奏混乱以及默认模板没有替换等问题。

总结

video-shotcraft 和 Archify 解决的是项目演示中的两个不同问题：

video-shotcraft：让产品展示更有镜头感和视觉节奏。
Archify：让系统架构和技术流程更容易理解。

它们不会自动替代完整的视频制作流程，但可以明显减少架构图绘制、镜头设计和动画开发中的重复工作。

对于需要经常发布 GitHub 项目、SaaS 产品、开发工具或技术方案的开发者，这套组合值得尝试。

项目地址

video-shotcraft：https://github.com/Vincentwei1021/video-shotcraft
Archify：https://github.com/tt-a1i/archify

AI Video Workflow：把选题、脚本、分镜到剪辑发布串成一条流程

Tue, 28 Jul 2026 14:35:00 +0800

制作一条视频，真正耗时的往往不是某一个步骤，而是在选题、写脚本、设计分镜、生成素材和剪辑软件之间反复切换。

AI Video Workflow 的核心，不是让 AI 按一下按钮就自动生成成片，而是把原本分散的视频制作环节整理成一套可以重复执行的工作流。

AI Video Workflow 能做什么？

一套完整的 AI 视频工作流通常包括以下环节：

1. 选题策划

先确定视频面向什么人、解决什么问题，以及适合发布到哪个平台。

AI 可以帮助完成：

根据账号定位生成选题
分析标题和内容角度
将一个主题拆成系列内容
为短视频、横屏视频生成不同方案

2. 脚本生成

确定选题后，AI 可以按照视频时长和表达方式生成脚本。

例如：

30 秒短视频口播稿
产品介绍脚本
工具使用教程
排行榜或资讯视频
带开头钩子和结尾行动引导的完整文案

脚本生成后仍需人工检查事实、数据和品牌信息，避免直接使用未经核实的内容。

3. 分镜与镜头规划

脚本可以继续拆分成分镜表，每个镜头包含：

画面内容
景别与机位
镜头时长
旁白或字幕
转场方式
所需图片、视频或动画素材

这样可以在生成素材之前，先确认整条视频的节奏和叙事结构。

4. 图片与视频提示词

AI 可以根据每个分镜生成对应的图片或视频提示词，并统一人物、场景和视觉风格。

提示词最好明确写出：

主体与动作
场景环境
镜头语言
光线与色调
视频比例
运镜方式
需要保持一致的角色特征

对于多镜头视频，角色一致性和场景连续性通常仍是最需要人工检查的部分。

5. 配音、字幕与素材生成

确定分镜后，可以继续生成：

AI 配音
背景音乐
音效
字幕文件
插图和封面
文生视频或图生视频素材

建议将脚本、配音、字幕和镜头编号统一保存，后期修改时更容易定位。

6. 剪辑与包装

AI 可以辅助完成粗剪、停顿删除、字幕识别、画面匹配和横竖屏适配。

最后仍需要人工确认：

画面是否与旁白一致
字幕是否准确
节奏是否拖沓
音乐是否盖住人声
是否存在错误素材或版权风险
开头几秒是否足够吸引人

7. 发布与内容复用

完成主视频后，还可以继续让 AI 生成：

视频标题
封面文案
简介和标签
小红书、抖音、YouTube 等平台版本
长视频切片
图文摘要
评论区置顶文案

一条视频因此可以继续拆成多种内容，而不是发布一次就结束。

AI Video Workflow 适合哪些人？

这套流程更适合：

经常制作短视频的个人创作者
需要批量制作固定栏目的团队
制作产品介绍和教程视频的企业
不熟悉专业分镜和剪辑流程的新手
希望减少重复操作的自媒体运营人员

它最大的价值不是完全代替创作者，而是把重复、机械和容易遗漏的环节标准化。

使用时需要注意什么？

AI 可以提高视频制作效率，但不能完全替代人工判断。

正式发布前，至少需要检查：

数据和事实是否准确
图片、音乐和视频素材是否可以商用
人物形象是否保持一致
字幕、配音和画面是否同步
内容是否符合发布平台规则

对于品牌宣传、新闻、医疗、金融等内容，还需要增加更严格的事实核查。

可参考的开源项目

ViMax

ViMax 是一个开源的智能视频生成框架，可以将创意或剧本继续拆分为故事、角色、脚本、分镜和镜头，并连接图片生成、视频生成与最终合成流程。

项目地址：

https://github.com/HKUDS/ViMax

需要注意的是，这类开源项目通常仍需配置大语言模型、图片生成模型和视频生成模型的 API，并不等于安装后完全免费生成视频。

总结

AI Video Workflow 的真正价值，是把视频创作从零散操作变成一条清晰、可修改、可复用的生产流程。

它可以帮助创作者完成选题、脚本、分镜、提示词、素材、剪辑和发布准备，但最终的视频质量，仍取决于内容判断、事实核查和人工精修。

Generative Media Skills：让 AI 编程助手生成图片、视频和音频

Tue, 28 Jul 2026 14:27:00 +0800

做 AI 内容创作时，图片、视频和音频通常需要分别打开不同的平台，不仅操作流程分散，提示词、素材和生成结果也不方便统一管理。

Generative Media Skills 是一套面向 AI Agent 的多模态生成工具集，可接入 Claude Code、Cursor、Gemini CLI 等 AI 编程助手，用自然语言完成图片、视频和音频的生成与编辑。项目采用结构化参数调用生成服务，重点不是再做一个聊天界面，而是把多媒体生成能力直接加入现有的 AI 工作流。

它能做什么？

Generative Media Skills 主要覆盖三类内容：

图片生成与编辑：根据文字描述生成图片，也可用于修改、扩展和处理现有画面。
视频生成：支持文字生成视频、图片生成视频等常见工作流。
音频生成：可生成语音、音乐或其他音频内容。

项目还提供可复用的生成方案、基础调用模块和 MCP Server，适合将多媒体生成能力接入自动化工作流，而不是每次都手动切换网站。

适合哪些人？

它比较适合以下使用场景：

使用 Claude Code、Cursor 或 Gemini CLI 的内容创作者。
需要批量生成封面图、短视频和配音的自媒体用户。
想把图片、视频和音频生成接入自动化流程的开发者。
需要统一管理生成提示词和媒体任务的小型内容团队。

例如，你可以直接告诉 AI：

为这篇文章生成一张科技风封面图，再制作一段 10 秒宣传视频，并生成中文旁白。

AI Agent 可以根据任务调用对应的媒体生成能力，减少在多个工具之间复制提示词和下载素材的步骤。

使用前需要注意

Generative Media Skills 本身更像一套 AI Agent 技能和调用框架，实际生成服务由 muapi.ai 提供，因此它并不等于完全离线、完全免费的本地生成软件。使用前应确认模型费用、生成额度、隐私政策以及不同模型的输出限制。

总结

Generative Media Skills 的价值，不是简单把图片、视频和音频功能放在一起，而是让 AI 编程助手能够直接调用这些生成能力。

对于已经使用 Claude Code、Cursor 或 Gemini CLI 的用户，它可以减少软件切换和重复操作，让多媒体内容生成更接近一套完整的自动化工作流。

GitHub 项目地址

https://github.com/SamurAIGPT/Generative-Media-Skills

Remotion：用 React 批量生成固定栏目、排行榜和数据周报

Tue, 28 Jul 2026 13:38:00 +0800

每周都要制作相似的视频内容，例如固定栏目、产品排行榜、行业数据周报，如果每次都重新改文字、换图片、调整动画，不仅耗时，还容易出现排版不一致的问题。

Remotion 提供了一种更适合批量生产的方式：使用 React、CSS、SVG、Canvas 等网页技术编写视频模板，再把标题、图片、排名、价格、数据和字幕作为参数传入，自动生成不同版本的视频。

Remotion 能做什么？

Remotion 的核心不是“自动剪辑”，而是用代码创建可重复使用的视频模板。

例如，可以先制作一个排行榜视频模板，然后只替换数据：

const rankingData = [
  { name: "项目 A", stars: 52000 },
  { name: "项目 B", stars: 43000 },
  { name: "项目 C", stars: 38000 },
];

当排行榜数据发生变化时，不需要重新设计视频，只需要更新数据，就可以再次渲染生成新的 MP4 文件。

适合哪些内容？

Remotion 特别适合结构固定、需要持续更新的视频内容，例如：

GitHub 热门项目排行榜
AI 工具推荐栏目
每周科技新闻速览
网站流量数据周报
电商产品榜单
股票或行业数据动画
批量商品宣传视频
个性化年度总结视频

对于这类内容，模板通常保持不变，变化的只是标题、图片、排名和数据，因此非常适合自动化生成。

为什么它能减少重复工作？

传统制作方式中，每一期视频都需要手动复制工程、修改文字、替换图片并重新检查动画。

使用 Remotion 后，可以把整个流程拆成三部分：

视频模板：负责画面布局、动画和转场。
内容数据：保存标题、图片、排行榜和统计数据。
渲染脚本：自动读取数据并输出 MP4 视频。

以后更新栏目时，只需要修改 JSON、表格或接口数据，就能生成新的视频内容。

Remotion 的主要优势

使用 React 编写视频，前端开发者容易上手
支持 CSS、SVG、Canvas 和 WebGL
视频中的文字、图片和数据都可以动态替换
可以连接 API、数据库或 JSON 文件
支持批量生成多个不同版本
最终可渲染为 MP4 视频
适合接入自动化内容生产流程

使用前需要注意

Remotion 更适合有一定前端或 JavaScript 基础的用户。它不是传统的拖拽式剪辑软件，第一次使用时仍需要编写模板和配置渲染环境。

另外，Remotion 采用特殊许可证。个人项目和部分小型项目通常可以使用，但企业在正式投入生产前，应查看官方最新许可证说明。

总结

Remotion 最有价值的地方，不是帮你做一条视频，而是帮你建立一套可以反复使用的视频生产系统。

固定栏目、排行榜、数据周报和批量营销视频，只需要设计一次模板，后续更新数据即可重新生成，能够明显减少重复剪辑和排版工作。

项目地址

GitHub：https://github.com/remotion-dev/remotion

video-use：把原始素材交给 AI，自动完成剪辑、字幕与调色

Tue, 28 Jul 2026 12:14:00 +0800

传统视频剪辑最耗时间的，往往不是拍摄，而是后期处理。

删除停顿、处理口头禅、生成字幕、调整画面颜色、添加转场和动效，这些操作并不复杂，但需要反复查看时间轴，非常消耗时间。

video-use 是一个开源 AI 视频剪辑项目。它可以配合 Claude Code 等 AI 编程代理，通过自然语言完成视频剪辑。你只需要把原始素材放进指定文件夹，再告诉 AI 想要什么效果，它就会分析视频并输出最终的 MP4 文件。

video-use 能做什么？

1. 自动删除停顿和口头禅

对于口播、教程和采访类视频，素材中经常会出现长时间停顿，以及“嗯”“啊”等无意义语气词。

video-use 可以先识别音频和字幕内容，再根据上下文判断需要删除的片段，减少手动查找剪切点的时间。

2. 自动生成并添加字幕

项目可以对视频语音进行转录，并将字幕添加到最终视频中。

相比单纯按照静音位置切割，它还会结合单词边界和字幕时间，尽量避免出现声音被截断、字幕与画面不同步等问题。

3. 自动调色和处理画面

你可以直接用自然语言提出要求，例如：

`1`	`让画面更明亮一些，增加对比度，并统一不同镜头的颜色。`

AI 会根据视频画面进行调色处理，也可以添加淡入淡出、缩放、字幕强调和动画叠加等效果。

4. 直接输出 MP4 视频

整个流程不需要频繁操作复杂的时间轴。

你可以把需求直接告诉 AI，例如：

删除视频中的停顿和口头禅。

为视频生成中文字幕。

给重点句子添加轻微放大效果。

统一画面颜色，并导出为 final.mp4。

video-use 会调用 FFmpeg 等工具执行剪辑，并将处理后的内容渲染成视频文件。

哪些人适合使用？

video-use 比较适合以下场景：

自媒体口播视频
软件操作教程
产品演示视频
访谈和播客片段
旅行视频与素材混剪
不想反复操作时间轴的内容创作者

它的优势不是完全替代专业剪辑软件，而是把大量重复操作交给 AI。

对于需要精细控制每一个镜头、音效和关键帧的商业项目，Premiere Pro、DaVinci Resolve 等传统剪辑软件仍然更加合适。但对于日常短视频、教程和口播内容，video-use 可以明显缩短基础剪辑时间。

使用思路

基本流程可以概括为：

准备原始视频
    ↓
将素材放入项目文件夹
    ↓
通过 Claude Code 输入剪辑要求
    ↓
AI 分析画面、语音和字幕
    ↓
自动执行剪切、字幕、调色和动效
    ↓
输出 final.mp4

需要注意的是，video-use 更接近一套面向 AI Agent 的视频剪辑工作流，并不是传统的可视化剪辑软件。

使用前通常需要准备 Claude Code、FFmpeg 及项目要求的相关运行环境。具体安装方式应以项目仓库中的最新 README 文档为准。

总结

video-use 把视频剪辑从“手动拖动时间轴”，变成了“用自然语言描述需求”。

把拍摄好的素材放进去，告诉 AI 删除停顿、生成字幕、调整颜色和添加动效，它就能自动完成大量基础后期工作。

对于经常制作口播、教程和短视频的创作者来说，这类 AI 视频剪辑工具真正节省的不是某一个操作，而是重复检查、修改和导出的时间。

项目地址

GitHub：

`1`	`https://github.com/browser-use/video-use`

HyperFrames：用一句提示词生成网页动画，并渲染为 MP4 视频

Tue, 28 Jul 2026 12:07:00 +0800

做产品演示、工具介绍或数据动画时，传统视频软件往往需要手动调整时间轴、关键帧和字幕，制作过程比较繁琐。

HyperFrames 提供了另一种思路：使用 HTML、CSS 和 JavaScript 编写视频画面，再将网页动画逐帧渲染成 MP4 文件。

它尤其适合配合 Claude Code、Codex 等 AI 编程助手使用。你只需要描述视频主题、画面风格和动画效果，AI 就可以帮助生成对应的网页动画代码，然后通过 HyperFrames 完成预览和视频导出。

HyperFrames 是什么？

HyperFrames 是 HeyGen 开源的 HTML 视频渲染框架。

它可以把 HTML 页面、CSS 样式、图片、视频素材和可控制的网页动画，转换为帧数稳定、结果可复现的 MP4 视频。

简单理解就是：

用写网页的方式制作视频，再把网页动画渲染成 MP4。

HyperFrames 本身并不是 Sora、Veo 这类直接生成真实画面的文生视频模型。所谓“一句话生成视频”，通常是让 AI 编程助手根据提示词生成 HTML、CSS 和 JavaScript，再调用 HyperFrames 完成渲染。

HyperFrames 可以做什么？

1. 制作产品宣传视频

可以用网页布局展示产品界面、功能卖点、价格方案和操作流程，适合制作 SaaS 产品介绍视频。

2. 生成动态数据视频

网页中的图表、数字、进度条和排行榜都可以加入动画，用于制作数据报告、业务汇报和社交媒体内容。

3. 制作文字与字幕动画

通过 CSS 或 GSAP 控制文字进入、缩放、渐变和切换效果，适合知识类短视频、教程和信息卡片。

4. 输出标准 MP4 文件

动画完成后，可以通过命令行直接渲染为 MP4，方便上传到抖音、视频号、YouTube 或其他视频平台。

为什么适合 AI 编程助手？

传统视频编辑依赖时间轴操作，而 HyperFrames 的视频内容本质上是代码。

这意味着 AI 可以直接修改：

视频尺寸和时长
文字内容与页面布局
CSS 动画和转场效果
图片、视频和音频素材
字幕、图表和品牌样式

例如，你可以直接告诉 AI：

使用 HyperFrames 创建一段 10 秒的产品介绍视频。

要求：
1. 画面比例为 16:9
2. 深色科技风格
3. 开头显示产品名称
4. 中间依次展示三个核心功能
5. 结尾显示网站地址
6. 添加平滑的文字进入和页面切换动画
7. 最后渲染为 MP4

AI 会根据要求生成视频页面，再通过 HyperFrames 进行预览和导出。

基本使用流程

第一步：安装 HyperFrames Skill

官方提供了适用于 AI 编程助手的 Skill，可以通过下面的命令安装：

`1`	`npx skills add heygen-com/hyperframes`

第二步：让 AI 生成视频页面

在 Claude Code、Codex 或其他支持 Skill 的 AI 工具中，描述视频主题、时长、比例和动画要求。

第三步：浏览器预览

HyperFrames 使用普通 HTML 作为视频内容，因此可以先在浏览器中查看动画效果，再继续修改。

第四步：渲染 MP4

准备好 HTML 文件后，可以运行：

`1`	`npx hyperframes render index.html`

HyperFrames 会逐帧录制网页动画，并输出 MP4 视频文件。

适合哪些用户？

HyperFrames 比较适合：

想用 AI 批量制作短视频的人
熟悉 HTML、CSS 或 JavaScript 的开发者
需要制作产品演示视频的独立开发者
想自动生成数据动画和信息视频的内容创作者
不想反复拖动传统视频时间轴的用户

不过，它更擅长制作网页动画、产品演示、字幕和动态图表，并不适合直接生成复杂的真人电影画面。

总结

HyperFrames 把网页开发和视频制作连接在了一起。

你可以先用一句提示词让 AI 生成 HTML 动画，再使用 HyperFrames 将动画稳定地渲染为 MP4。对于产品介绍、数据展示、教程动画和批量短视频制作来说，这种工作方式比传统手动剪辑更容易自动化和重复使用。

项目地址

GitHub：https://github.com/heygen-com/hyperframes
官方网站：https://hyperframes.heygen.com/

WorkBuddy + HyperFrames 安装教程：接入本地 Qwen3-TTS，实现自己的声音自动配音

Tue, 28 Jul 2026 11:55:00 +0800

想用 AI 自动生成动画视频，但不熟悉 Node.js、FFmpeg、命令行和环境配置？

一种更省事的方案是：使用 WorkBuddy 协助安装和排查问题，用 HyperFrames 把 HTML 动画渲染成 MP4，再通过桥接脚本接入本地 Qwen3-TTS，实现字幕、画面和个人声音配音的一体化制作。

一、三个工具分别做什么？

WorkBuddy

WorkBuddy 是腾讯推出的桌面 AI Agent。它不仅能回答问题，还可以协助执行命令、安装依赖、修改文件和分析报错。

在这套流程中，它主要负责：

检查电脑环境
安装 HyperFrames
执行终端命令
分析安装报错
编写 Qwen3-TTS 桥接脚本
调整视频项目文件

需要注意的是，WorkBuddy 本身不是 HyperFrames 的必要依赖。熟悉命令行的用户，也可以手动完成全部操作。

HyperFrames

HyperFrames 是 HeyGen 开源的 HTML 转视频框架。

它允许开发者使用 HTML、CSS、JavaScript 和动画时间轴制作画面，再按照固定帧逐帧渲染为 MP4 视频。

适合制作：

产品介绍动画
数据可视化视频
知识讲解视频
字幕配音视频
网页演示视频
社交媒体短视频

与传统录屏不同，HyperFrames 使用确定性的逐帧渲染方式。同一个项目重复渲染时，画面和动画时间通常能够保持一致。

Qwen3-TTS

Qwen3-TTS 是通义千问团队开源的语音生成模型，支持文本转语音、音色设计和声音克隆。

将它部署在本地后，可以用参考音频生成接近目标音色的配音，不必每次调用第三方在线语音接口。

请只克隆自己拥有授权的声音，不要冒用他人身份或未经允许复制他人音色。

二、安装前需要准备什么？

本文以 Windows 环境为例。

建议提前准备：

Node.js
FFmpeg
WorkBuddy
已部署的 Qwen3-TTS，可选
足够的磁盘空间

如果暂时没有 Qwen3-TTS，也可以先完成 HyperFrames 的安装和视频渲染，后续再接入本地配音。

三、安装 Node.js

前往 Node.js 官网下载长期支持版，也就是 LTS 版本。

安装完成后，打开 PowerShell 或 Windows Terminal，执行：

1
2

node -v
npm -v

如果能够正常显示版本号，说明 Node.js 和 npm 已安装成功。

例如：

1
2

v22.x.x
10.x.x

如果系统提示找不到 node 命令，可以尝试：

关闭并重新打开终端。
重启电脑。
检查 Node.js 是否已加入系统环境变量。

四、安装 FFmpeg

以管理员身份打开 PowerShell，然后执行：

`1`	`winget install --id Gyan.FFmpeg`

安装完成后，重新打开终端并检查：

`1`	`ffmpeg -version`

能够看到 FFmpeg 的版本和编译信息，即表示安装成功。

如果 winget 无法使用，也可以从 FFmpeg 官方网站下载 Windows 构建版本，再手动配置环境变量。

五、安装 WorkBuddy

前往 WorkBuddy 官方网站，下载适合 Windows 或 macOS 的客户端。

安装并登录后，可以先让 WorkBuddy检查当前环境：

`1`	`请检查这台电脑是否已经安装 Node.js、npm 和 FFmpeg，并分别输出版本号。缺少的依赖请告诉我具体安装方法。`

这样做的好处是，可以先发现环境问题，再开始安装 HyperFrames，避免安装到一半才发现依赖缺失。

六、使用 WorkBuddy 安装 HyperFrames

打开 WorkBuddy，新建一个空文件夹作为视频项目目录，然后输入：

`1`	`请在当前目录安装 HyperFrames，并创建一个可以预览和渲染的最小示例项目。完成后检查 Node.js、FFmpeg 和浏览器渲染依赖是否正常。`

也可以手动安装 HyperFrames Skill：

`1`	`npx skills add heygen-com/hyperframes --yes`

安装完成后，可以让 WorkBuddy 创建一个简单测试视频：

请使用 HyperFrames 创建一个 8 秒的 16:9 测试视频。

要求：
1. 深色背景。
2. 中间显示“Hello HyperFrames”。
3. 文字淡入并轻微向上移动。
4. 最后导出为 MP4。

七、运行环境体检

在项目目录中执行：

`1`	`npx hyperframes doctor`

部分安装方式可能也支持：

`1`	`hyperframes doctor`

建议优先使用 npx hyperframes，因为它会调用当前项目使用的版本，能够减少全局版本和项目版本不一致的问题。

环境体检通常会检查：

Node.js
FFmpeg
浏览器或 Chromium
HyperFrames 项目配置
视频渲染相关依赖

如果出现报错，不要只发送最后一行错误。建议把完整终端输出复制给 WorkBuddy：

1
2
3

下面是执行 npx hyperframes doctor 后的完整报错。

请先判断是哪项依赖失败，再给出修复步骤。不要删除现有项目文件，也不要升级无关依赖。

八、预览和渲染视频

创建好 HTML 动画项目后，可以先预览：

`1`	`npx hyperframes preview`

确认画面、动画和字幕没有问题后，再执行渲染：

`1`	`npx hyperframes render index.html`

也可以指定输出文件：

`1`	`npx hyperframes render index.html --output output.mp4`

不同版本的命令参数可能有所变化。如果命令报错，应先运行：

`1`	`npx hyperframes --help`

以当前安装版本显示的命令为准。

九、接入本地 Qwen3-TTS

HyperFrames 负责画面渲染，Qwen3-TTS 负责生成配音。两者之间通常需要增加一个桥接层。

整体流程如下：

视频文案
   ↓
桥接脚本
   ↓
本地 Qwen3-TTS 接口
   ↓
生成 WAV 或 MP3
   ↓
HyperFrames 读取音频
   ↓
根据音频时长生成字幕和动画
   ↓
导出 MP4

桥接脚本主要负责：

接收需要配音的文字。
调用本地 Qwen3-TTS。
指定参考音频和参考文本。
保存生成的音频。
把音频文件路径返回给 HyperFrames。

十、让 WorkBuddy 编写桥接脚本

假设本地 Qwen3-TTS 已经提供 HTTP API，可以向 WorkBuddy 输入：

我的本地 Qwen3-TTS 服务已经启动，请为当前 HyperFrames 项目编写一个 TTS 桥接脚本。

要求：
1. 接收中文文本。
2. 调用本地 Qwen3-TTS HTTP API。
3. 支持配置 API 地址、参考音频和参考文本。
4. 将生成结果保存到 public/audio 目录。
5. 返回音频文件路径和音频时长。
6. 请求失败时输出明确的错误信息。
7. 不要把本地路径和接口地址写死，统一放到 .env 文件中。
8. 同时生成 .env.example 和使用说明。

建议在 .env 中保存类似配置：

1
2
3

QWEN_TTS_API_URL=http://127.0.0.1:8000
QWEN_TTS_REF_AUDIO=D:/voice/reference.wav
QWEN_TTS_REF_TEXT=这里填写参考音频对应的准确文字

不要把真实的本地路径、密钥或个人声音样本提交到公开 GitHub 仓库。

可以在 .gitignore 中加入：

.env
public/audio/
private/
*.wav

十一、一个容易忽略的问题：接口格式不一定相同

“已经部署 Qwen3-TTS”并不代表所有项目都使用相同接口。

不同的本地部署项目可能使用：

Python 函数调用
FastAPI 接口
Gradio 接口
OpenAI 兼容接口
自定义 WebSocket 接口

因此，桥接脚本不能直接照搬。至少要先确认：

接口地址：
请求方法：
请求参数：
返回格式：
音频格式：
是否需要参考音频：
是否需要参考文本：

可以让 WorkBuddy读取本地 Qwen3-TTS 项目的 README 或接口代码，然后根据真实接口编写适配脚本。

推荐提示词：

`1`	`请读取这个 Qwen3-TTS 项目的 README 和服务端接口代码，确认真实的请求地址、参数和返回格式，再修改 HyperFrames 桥接脚本。不要猜测接口字段。`

十二、生成自己的声音配音

Qwen3-TTS 的声音克隆通常需要准备：

一段清晰的参考音频
参考音频对应的准确文字
需要生成的新文案

参考音频建议：

环境安静
没有背景音乐
没有明显混响
只有一个人说话
发音清楚
参考文本与录音内容一致

完成配置后，可以让 WorkBuddy执行测试：

请使用本地 Qwen3-TTS 生成一段中文测试配音，文案为：

“这是通过 HyperFrames 和本地语音模型生成的一段测试视频。”

生成后检查音频是否可以正常播放，再把它加入 HyperFrames 时间轴，并生成同步字幕。

确认试听结果正常后，再开始生成正式视频。

十三、常见问题

1. 找不到 `hyperframes` 命令

优先尝试：

`1`	`npx hyperframes --help`

如果可以运行，说明 HyperFrames 安装在当前项目，而不是全局环境。

2. FFmpeg 已安装，但终端仍然找不到

关闭所有终端窗口后重新打开。

仍然无效时，检查 FFmpeg 的 bin 目录是否已经加入系统 Path。

3. 浏览器下载失败

可能与网络、代理、防火墙或缓存有关。

可以把完整错误日志交给 WorkBuddy，重点检查：

下载地址是否可以访问
系统代理是否生效
防火墙是否拦截
磁盘空间是否充足
浏览器缓存目录是否损坏

4. 视频有画面但没有声音

检查：

音频文件是否真实存在
HTML 中的文件路径是否正确
音频格式是否受支持
音频是否加入时间轴
渲染时 FFmpeg 是否检测到音轨

5. 字幕和配音不同步

不要只按照文字长度估算时间。

更可靠的方式是先生成音频，再读取真实音频时长，根据句子或时间戳安排字幕和动画。

6. 自己的声音不像

重点检查：

参考音频是否清晰
参考文本是否准确
是否选择了支持声音克隆的 Base 模型
音频中是否包含噪声、音乐或多人说话
桥接脚本是否正确传递参考音频

十四、这套方案适合谁？

这套工作流适合：

不熟悉命令行的内容创作者
想批量制作知识类视频的人
需要自动生成字幕和配音的人
希望减少在线视频工具费用的人
已经部署本地语音模型的用户
想用 HTML、CSS 和 JavaScript 制作动画的人

它的核心价值不是“完全不用配置”，而是让 AI Agent 帮助完成重复安装、脚本适配和错误排查，把视频生产流程从多个工具之间的手动切换，变成相对统一的自动化工作流。

总结

WorkBuddy、HyperFrames 和 Qwen3-TTS 分别解决了三个问题：

WorkBuddy：负责安装、执行和排错。
HyperFrames：负责把 HTML 动画渲染成 MP4。
Qwen3-TTS：负责本地语音生成和个人音色配音。

真正关键的环节，是根据本地 Qwen3-TTS 的真实接口编写桥接脚本，而不是简单复制一段固定代码。

完成桥接后，就可以形成一条相对完整的自动化流程：

输入视频主题
→ AI 生成脚本和 HTML 动画
→ Qwen3-TTS 生成配音
→ 自动生成字幕
→ HyperFrames 渲染 MP4

项目与官方地址

WorkBuddy 官方介绍：https://docs.cloudbase.net/ai/ai-tools/workbuddy
HyperFrames GitHub：https://github.com/heygen-com/hyperframes
HyperFrames 文档：https://hyperframes.heygen.com/
Qwen3-TTS GitHub：https://github.com/QwenLM/Qwen3-TTS

5个自定义 Skills，让 Codex 从代码生成器升级为全能 AI 开发助手

Tue, 28 Jul 2026 11:34:00 +0800

很多人使用 Codex 时，只让它完成“写代码”这一件事。

遇到需求就生成代码，出现报错再继续修改。这样的使用方式虽然方便，但 Codex 很难理解项目背景，也容易出现需求理解偏差、界面模板化、修改范围过大等问题。

更有效的方法，是通过 Agent Skills 为 Codex 增加固定的知识、规则和工作流程。

Skill 本质上是一组可重复使用的说明、脚本和资源。它可以让 Codex 在执行特定任务时，按照预先设定的流程工作，而不是每次都依赖临时提示词。OpenAI 的 Skills 项目也将其定义为帮助 Codex 扩展专业能力的模块化目录。¹

下面这 5 个 Skill，分别解决知识管理、方案审查、UI 设计、中文写作和代码质量问题。

一、obsidian-skills：把 Obsidian 变成 Codex 的知识库

在长期项目中，真正影响 AI 工作质量的往往不是模型能力，而是它不知道你之前做过什么。

例如：

项目已经确定了哪些技术方案
哪些错误曾经出现过
用户有哪些固定偏好
某项设计为什么被放弃
当前项目有哪些待办事项

obsidian-skills 可以让 Codex 读取和管理 Obsidian 知识库中的 Markdown 笔记、任务、属性、Bases 和 JSON Canvas。

该项目遵循 Agent Skills 规范，并明确支持 Codex CLI 等兼容 Skills 的 AI 编程工具。²

它能解决什么问题

使用这个 Skill 后，可以让 Codex：

搜索 Obsidian 中的历史笔记
创建和更新项目文档
整理零散的开发记录
查找与当前任务相关的内容
将解决方案沉淀为长期知识
根据历史记录继续未完成的工作

适合的使用场景

例如你可以告诉 Codex：

1
2
3

搜索 Obsidian 中与当前网站部署有关的笔记，
整理已经尝试过的方法、失败原因和最终解决方案，
然后根据这些信息继续排查问题。

这样可以减少重复解释项目背景，也能避免 AI 再次尝试已经失败的方法。

需要注意：它主要负责帮助 AI 操作和整理 Obsidian 知识库，并不等于自动拥有完整的长期记忆。最终效果仍取决于你的笔记结构和记录质量。

二、UI Skill：减少 AI 生成网页的模板感

AI 可以快速生成网页，但生成结果经常存在明显的“AI 模板感”。

常见问题包括：

不分场景地使用紫蓝渐变
所有内容都居中排列
页面由大量相似卡片组成
默认使用常见字体和圆角
只考虑桌面端，没有检查移动端
视觉效果不错，但真实上线后不好使用

UI Skill 的作用不是提供一个固定模板，而是给 Codex 增加一套设计判断标准。

目前 GitHub 上已经有多种面向 Codex 的 UI Skills。例如 ui-ux-pro-max-skill 提供了 UI 风格、配色、字体组合、产品类型、UX 规则和图表类型等设计知识，可用于网页和移动端界面的规划、生成、审查与优化。³

1. 建立设计黑名单

可以在 Skill 中明确禁止一些容易产生模板感的设计：

除非项目明确要求，否则不要默认使用：

- 紫色到蓝色的渐变背景
- 所有标题和内容居中对齐
- 大量相同尺寸的信息卡片
- 缺乏层级的圆角矩形
- 没有业务含义的装饰性光效
- 默认套用科技 SaaS 网站风格

设计黑名单并不是完全禁止这些元素，而是要求 Codex 在使用前说明理由。

2. 根据业务选择设计语言

品牌官网、个人博客和后台管理系统，不应该使用完全相同的设计方式。

Skill 可以要求 Codex先判断页面类型：

页面类型	设计重点
品牌落地页	品牌识别、视觉节奏、转化路径
个人博客	阅读体验、内容层级、页面速度
后台系统	信息密度、操作效率、状态反馈
电商页面	商品信息、信任感、购买路径
工具网站	功能入口、操作引导、结果展示

3. 增加上线前质检

页面完成后，要求 Codex 检查：

手机端图片是否变形
长英文和链接是否可以换行
按钮是否有明确反馈
文字对比度是否足够
页面加载是否依赖过大的图片
表单是否提供错误提示
页面是否存在横向溢出
键盘操作是否正常

这样可以让 Codex 从“生成一个好看的页面”，升级为“交付一个可以实际使用的页面”。

三、Humanizer-zh：减少中文内容的 AI 味

Codex 不只能写代码，也经常被用于生成：

产品介绍
README 文档
博客文章
更新日志
网站文案
操作说明
社交媒体内容

但 AI 生成的中文常常存在表达生硬、结构重复和营销感过强的问题。

Humanizer-zh 是一个中文内容优化 Skill，主要用于识别并减少 AI 写作痕迹，让文字更自然、更接近真实中文表达。其项目说明中明确提到，它可以用于编辑或审阅 AI 生成的文本。⁴

常见的 AI 写作问题

它可以重点检查以下内容：

频繁使用“值得注意的是”
每段都使用相同句式
过度使用“赋能”“重塑”“开启新篇章”
没有事实支撑的夸张表达
大量使用“首先、其次、最后”
句子看似完整，但缺少具体信息
中文中出现明显的英文翻译腔

使用示例

完成网站文章后，可以让 Codex 执行：

使用 Humanizer-zh 检查这篇文章。

要求：
1. 删除空泛和夸张的营销表达；
2. 保留技术事实、命令和项目名称；
3. 调整重复句式；
4. 使用自然、简洁的中文；
5. 不要为了口语化而降低专业性。

它适合作为内容发布前的最后一道编辑流程，而不是简单地把所有内容改成口语。

四、grill-me：在开发之前先把方案问清楚

AI 编程最常见的问题之一，是需求还没有明确，AI 就已经开始写代码。

结果通常是：

技术路线选择错误
功能边界不断扩大
忽略重要异常情况
修改大量无关文件
做完以后才发现需求理解错了

grill-me 的作用，就是在动手开发前扮演一个严格的方案审查者。

该 Skill 会围绕计划、设计或技术方案持续追问，直到关键决策、假设和分支得到明确。⁵

它会重点追问什么

例如开发一个用户登录功能时，grill-me 不会立刻生成代码，而是先检查：

使用邮箱、手机号还是第三方账号登录
是否需要注册、找回密码和邮箱验证
登录状态保存多久
是否允许多设备同时登录
失败次数是否需要限制
用户数据存储在哪里
哪些页面需要登录后访问
是否存在管理员和普通用户权限

使用示例

使用 grill-me 审查下面的开发方案。

在需求和边界没有明确之前，不要编写代码。
请重点检查：

- 隐含假设
- 异常流程
- 数据安全
- 权限设计
- 技术复杂度
- 后期维护成本

这个 Skill 看起来会让前期讨论变慢，但通常能减少后期返工。

五、编码原则 Skill：限制 Codex 的修改范围

前面四个 Skill 解决了知识、方案、设计和内容问题，最后还需要一套编码原则来限制 Codex 的执行行为。

这部分不一定需要安装现成项目，也可以根据自己的开发习惯创建一个自定义 SKILL.md。

五个 Skill 如何组成完整工作流

这五个 Skill 并不是相互独立的工具，可以按照开发流程组合使用。

第一步：读取历史知识

使用 obsidian-skills 搜索项目笔记、历史方案和踩坑记录。

第二步：审查需求

使用 grill-me 挑战需求和技术方案，找出缺失信息与边界情况。

第三步：设计并实现界面

使用 UI Skill 确定设计语言、页面结构、响应式规则和质检标准。

第四步：优化文字内容

使用 Humanizer-zh 调整页面文案、README 和博客内容，减少机械化表达。

第五步：完成最小修改并验证

使用编码原则 Skill 限制修改范围，并执行测试、构建和代码检查。

完整流程可以概括为：

历史知识检索
    ↓
需求追问与方案审查
    ↓
UI 设计与代码实现
    ↓
中文内容优化
    ↓
测试、验证与交付

实际使用时，不需要每次启用全部 Skill

五个 Skill 不一定每次都要同时使用。

可以根据任务类型进行组合：

任务	推荐 Skill
整理项目经验	obsidian-skills
开发复杂新功能	obsidian-skills + grill-me + 编码原则
制作网站页面	UI Skill + Humanizer-zh + 编码原则
编写技术文章	obsidian-skills + Humanizer-zh
重构旧项目	grill-me + 编码原则
制作产品落地页	UI Skill + Humanizer-zh
排查历史问题	obsidian-skills + 编码原则

Skill 数量并不是越多越好。真正重要的是每个 Skill 都有明确职责，并且不会互相冲突。

总结

Codex 的价值不只是生成代码。

通过 Skills，可以将知识、规范和工作流程固定下来，让 Codex逐渐具备以下能力：

读取并整理项目知识
在开发前审查需求
根据业务选择设计语言
优化中文内容表达
控制代码修改范围
在交付前完成自我验证

最终目标不是让 Codex 一次生成更多代码，而是减少沟通成本、降低返工概率，让每次修改都更加稳定和可控。

GitHub 项目地址

“编码原则”部分属于可自行创建的自定义 Skill，并非本文确认的单一 GitHub 项目。

OpenAI Skills 项目将 Agent Skills 描述为由指令、脚本和资源组成的模块化目录，可帮助 Codex 重复执行特定任务。 ↩︎
obsidian-skills 项目说明其遵循 Agent Skills 规范，并支持 Codex CLI。 ↩︎
UI UX Pro Max Skill 提供多种设计风格、配色、字体组合、UX 规则与技术栈支持。 ↩︎
Humanizer-zh 用于识别和减少中文文本中的 AI 生成痕迹。 ↩︎
grill-me 用于通过持续追问，对计划、需求或设计方案进行压力测试。 ↩︎

用 AI 做深度研究：STORM 方法图解与 4 组实用提示词

Tue, 28 Jul 2026 11:22:00 +0800

很多人使用 AI 做研究时，采用的方式仍然是：

提出一个问题，等待 AI 给出一段完整答案。

这种方法适合快速了解概念，却很难完成真正的深度研究。

原因很简单：当问题比较复杂时，不同领域、不同利益关系和不同立场的人，往往会得出完全不同的结论。只让 AI 给出一个答案，通常只能得到经过压缩的主流观点，而看不到观点之间的矛盾、证据强弱和尚未解决的问题。

更有效的方法，是让 AI 先从多个视角提出问题，再检索资料、比较证据、整理冲突，最后形成结构化结论。

这正是斯坦福大学 OVAL 实验室提出的 STORM 方法所关注的问题。

一、什么是 STORM？

STORM 的全称是：

Synthesis of Topic Outlines through Retrieval and Multi-perspective Question Asking

可以理解为：

通过信息检索和多视角提问，综合生成主题大纲。

STORM 是斯坦福 OVAL 实验室开发的一套 AI 知识研究与长文生成系统。它的目标并不是让 AI 直接写出答案，而是在写作之前先完成更充分的资料调查。

其核心流程包括：

发现与研究主题相关的不同视角；
模拟不同视角的提问者；
根据可靠的网络资料回答问题；
整理收集到的信息；
生成结构化文章大纲；
按照大纲撰写带有引用来源的长文。

因此，STORM 更适合处理需要多来源、多视角和结构化分析的复杂问题。

例如：

某项新技术是否值得采用；
一个商业模式是否可持续；
某个行业未来可能如何变化；
一项政策会影响哪些群体；
一个产品是否值得长期投入；
某个社会观点是否有充分证据支持。

需要注意的是，下面介绍的“四步提示词工作流”并不是 STORM 官方固定模板，而是根据其多视角提问、检索、整理与验证思想改造出来的实用方法。

二、第一步：多视角扫描

面对复杂问题时，不要立即要求 AI 给出最终结论。

第一步应该让 AI 从多个角色出发，分别提出观点、证据和疑问。

多视角扫描提示词

将下面的提示词复制给支持联网搜索的 AI，并替换其中的研究主题。

你是一名深度研究助手。

请围绕以下主题展开多视角研究：

【研究主题】
在这里填写需要研究的问题。

请分别模拟以下五种角色：

1. 实践者：关注真实执行经验、现实限制和理论与实际之间的差距。
2. 学者：关注同行评审研究、理论模型、数据质量和学术共识。
3. 怀疑者：挑战主流观点，提出最有力的反方论证。
4. 经济学家：分析利益关系、成本结构、激励机制和资源分配。
5. 历史学家：寻找历史案例、长期规律和类似事件。

每个角色分别输出：

- 核心立场；
- 支持该立场的三个主要论据；
- 可以查证的证据或来源；
- 该视角最担心的问题；
- 一个其他角色可能忽略的重要信息；
- 当前结论的置信度，使用高、中、低表示。

要求：

- 不得虚构研究、统计数据、专家观点或来源；
- 将事实、推测和观点分开表达；
- 优先引用原始资料、官方文件和学术论文；
- 无法确认的信息必须明确标注；
- 不要急于给出统一结论。

这一步的重点不是马上判断谁对谁错，而是尽可能展开问题的不同侧面。

三、第二步：绘制矛盾图

多视角研究真正有价值的地方，不是得到五段相似的介绍，而是发现它们之间的分歧。

例如：

学术研究认为某种方法有效，但实践者认为执行成本太高；
经济学家认为市场会迅速接受，但历史学家发现类似技术曾多次失败；
多数观点支持某项政策，但怀疑者指出研究样本存在偏差。

这些冲突往往比单独的观点更值得研究。

矛盾图需要分析什么？

1. 直接矛盾

找出无法同时成立的结论。

例如：

1
2
3

观点 A：AI 可以显著降低企业运营成本。

观点 B：企业部署 AI 后，短期运营成本反而会上升。

这两个观点看似冲突，但可能分别讨论了长期成本和短期成本。

因此，还需要继续检查：

双方讨论的是不是同一时间范围；
使用的是不是同一种衡量标准；
研究对象是否相同；
是否存在隐藏的前提条件。

2. 证据强弱

不是所有观点都具有相同可信度。

可以按照以下顺序评估来源：

原始数据和官方文件；
同行评审论文；
系统性综述或专业机构报告；
企业公开报告；
专家访谈；
新闻报道；
个人经验；
无法验证的网络观点。

来源级别高，并不代表结论一定正确，但通常更容易核验。

3. 跨视角共识

如果立场不同的角色仍然同意某个判断，这部分信息通常更值得重视。

例如，实践者、学者和怀疑者可能都认为：

当前证据不足以支持大规模部署。

这类跨立场共识，可以作为阶段性判断的重要依据。

4. 研究空白

还要检查哪些关键问题没有被任何角色提到。

常见空白包括：

缺乏长期数据；
没有分析失败案例；
忽略特定地区或人群；
缺少实际成本数据；
没有讨论实施条件；
没有考虑政策变化；
只引用单一语言或单一国家的资料。

矛盾分析提示词

请基于上一轮五个角色的研究结果，绘制一份“观点矛盾图”。

按照以下结构输出：

## 一、主要观点列表

列出每个角色最核心的结论。

## 二、直接冲突

找出彼此对立或无法同时成立的观点。

对每组冲突分别说明：

- 冲突双方；
- 具体分歧；
- 双方使用的证据；
- 双方是否讨论了不同对象、时间范围或前提条件；
- 当前哪一方的证据更强；
- 还需要什么信息才能解决争议。

## 三、证据强度排序

将主要观点按照证据可靠性排序，并说明理由。

优先考虑：

1. 原始数据；
2. 官方资料；
3. 同行评审论文；
4. 专业机构报告；
5. 企业资料；
6. 新闻报道；
7. 专家或个人观点。

## 四、跨视角共识

找出多个角色共同认可的部分，并说明：

- 有多少角色支持；
- 是否存在可靠来源；
- 是否可以视为阶段性事实；
- 仍有哪些限制条件。

## 五、研究盲区

指出当前分析中无人讨论或证据不足的领域。

要求：

- 不要为了形成结论而强行消除矛盾；
- 将事实冲突和价值判断冲突分开；
- 对证据不足的部分明确标注“不确定”；
- 不得用来源数量代替来源质量。

四、第三步：合成研究简报

完成多视角扫描和矛盾分析后，再让 AI 整合信息。

这时生成的结论会比直接提问更有层次，因为 AI 已经知道：

有哪些主要观点；
哪些观点存在冲突；
哪些证据比较可靠；
哪些问题仍然没有答案。

一份合格的研究简报应该包含什么？

1. 一句话总结

用一句话概括当前最重要的研究结论。

它不应该只是重复标题，而应该直接回答：

综合现有证据，目前最合理的判断是什么？

2. 五个关键发现

按照可靠程度排序，而不是按照表达是否精彩排序。

每个发现应该包含：

结论；
主要证据；
反方意见；
适用条件；
置信度。

3. 隐藏的关联

寻找只有结合多个视角才能发现的关系。

例如：

技术效果很好，但组织激励阻碍了落地；
市场需求真实存在，但现有商业模式无法盈利；
学术证据支持短期效果，却缺少长期风险数据；
历史案例失败，并非技术问题，而是成本和监管问题。

这类跨视角联系，往往是深度研究最有价值的部分。

4. 可操作建议

研究结果最终要能够帮助用户做出判断或采取行动。

建议应该具体到：

先做什么；
暂时不要做什么；
需要验证什么；
应该设置什么条件；
在什么情况下停止；
在什么情况下扩大投入。

5. 下一步研究问题

一份可信的研究不会假装所有问题都已经解决。

它应该明确指出：

哪些结论仍然不确定；
需要补充哪些数据；
哪些变量最可能改变结论；
未来应该持续关注什么。

研究简报提示词

请基于前面的多视角研究和矛盾分析，生成一份结构化研究简报。

按照以下格式输出：

# 研究主题

## 一句话结论

用一句准确、克制的语言概括当前最重要的发现。

## 五个关键发现

按照可靠性从高到低排序。

每个发现包含：

- 结论；
- 主要证据；
- 支持来源；
- 反方观点；
- 适用条件；
- 置信度。

## 主要争议

总结目前仍未解决的核心矛盾，并说明争议产生的原因。

## 隐藏的关联

列出至少三个只有综合多个视角才能发现的深层联系。

## 可操作建议

分别给出：

- 现在可以执行的行动；
- 执行前需要验证的条件；
- 暂时不建议采取的行动；
- 需要持续观察的指标。

## 研究限制

说明资料、数据、时间范围、地域和研究方法存在的限制。

## 下一步问题

列出五个值得进一步研究的问题。

要求：

- 不要把推测写成事实；
- 不要隐藏相互矛盾的证据；
- 每项重要结论尽量附带可核验来源；
- 建议必须能够追溯到前面的研究发现；
- 没有充分证据时，使用审慎措辞。

五、第四步：让 AI 自我评估

AI 给出结构化报告之后，还不能立即把它当作最终答案。

最后一步是让 AI 重新审视自己的研究过程。

这一步主要用于发现：

证据不足；
来源质量不高；
观点偏向单一；
推理跳跃；
结论过度确定；
忽略反例；
将相关性误写成因果关系。

自我评估的四个重点

1. 结论置信度

让 AI 对每个关键结论分别评分，而不是只给整篇报告一个总分。

可以采用以下标准：

高置信度：多个高质量独立来源相互支持；
中等置信度：有一定证据，但存在范围或方法限制；
低置信度：证据较少、来源单一或主要依赖推测。

2. 最薄弱的部分

要求 AI 主动指出：

哪个发现证据最少；
哪条因果关系最可疑；
哪个数据最可能过时；
哪个来源可能存在利益冲突；
哪项建议最依赖特定假设。

3. 视角偏差

检查研究是否遗漏了重要群体。

例如：

只分析企业，没有分析消费者；
只分析支持者，没有分析反对者；
只分析欧美市场，没有分析其他地区；
只关注技术，没有关注法律和伦理；
只看成功案例，没有看失败案例。

4. 外部专家审查

可以让 AI 模拟教授、行业专家或审稿人进行批评。

但要注意：模拟评分只是帮助发现问题，不能代替真实专家评审。

自我评估提示词

请对上一份研究简报进行严格的自我评估。

不要继续扩写报告，而是站在审稿人的角度寻找问题。

按照以下结构输出：

## 一、结论置信度

对每个关键发现分别给出：

- 置信度：高、中或低；
- 支持该结论的证据；
- 降低可信度的因素；
- 哪些新证据可能改变结论。

## 二、最薄弱的三个环节

分别说明：

- 薄弱点是什么；
- 为什么薄弱；
- 是否存在推理跳跃；
- 应该补充什么资料。

## 三、来源质量检查

检查：

- 是否过度依赖单一来源；
- 是否引用了二手资料而没有找到原始来源；
- 是否存在利益冲突；
- 是否混用了不同时间、地区或统计口径的数据；
- 是否存在无法核验的来源。

## 四、视角偏差检查

分析：

- 哪个角色的影响过大；
- 哪些关键利益相关者没有被纳入；
- 是否遗漏法律、伦理、环境、地域或文化视角；
- 是否忽略失败案例和反例。

## 五、推理错误检查

重点检查：

- 是否把相关性当成因果关系；
- 是否存在过度概括；
- 是否以偏概全；
- 是否使用未经证明的前提；
- 是否因为多数观点一致就直接判断为事实。

## 六、模拟专家评分

假设由一位严格的大学教授或行业研究负责人评分：

- 研究广度：满分20分；
- 证据质量：满分20分；
- 逻辑严谨性：满分20分；
- 反方观点处理：满分20分；
- 可操作性：满分20分。

给出总分，并说明最需要修改的三处内容。

## 七、修订建议

按优先级列出下一轮研究需要完成的工作。

要求：

- 不要为原报告辩护；
- 优先寻找可能推翻结论的证据；
- 明确区分已知事实、合理推断和未知信息；
- 不得虚构新的来源。

六、如何连续使用这四组提示词？

实际操作时，可以按照以下顺序执行：

确定研究问题
↓
多视角扫描
↓
绘制矛盾图
↓
合成研究简报
↓
执行自我评估
↓
补充检索与人工核验
↓
形成最终结论

不要一次把四组提示词全部发给 AI。

更合适的方法是逐步执行，因为每一步都需要检查上一轮结果。

例如：

先执行多视角扫描；
删除明显无关或重复的观点；
要求 AI 补充缺失来源；
再执行矛盾分析；
检查冲突是否真实存在；
再生成研究简报；
最后执行自我评估；
人工打开关键来源进行核验。

这样能够减少错误在不同阶段不断累积。

七、如何提出一个适合深度研究的问题？

问题越模糊，研究结果越容易变成泛泛介绍。

不推荐这样问：

`1`	`AI 未来怎么样？`

可以改成：

`1`	`未来三年，生成式 AI 会如何影响中国中小型外贸企业的内容营销、人力成本和客户服务？请重点分析实际部署成本、数据安全和投资回报。`

不推荐这样问：

`1`	`独立站还有必要做吗？`

可以改成：

`1`	`对于预算有限的中国中小企业，在 Google 搜索流量受到 AI Overview 影响的情况下，2026 年继续建设品牌独立站是否仍然具有长期价值？`

一个好的研究问题通常包含：

研究对象；
时间范围；
地域范围；
需要比较的方案；
关注的指标；
最终需要支持的决策。

八、STORM 方法适合哪些场景？

STORM 式多视角研究更适合以下任务：

商业决策

例如：

是否进入一个新市场；
是否采用某项新技术；
是否更换供应商；
是否开发某类产品；
是否调整营销渠道。

行业研究

例如：

AI 搜索会如何影响传统 SEO；
自动化会如何改变某个职业；
某类材料是否具备增长潜力；
某项政策会怎样影响行业。

产品与技术选型

例如：

WordPress 与 Next.js 如何选择；
是否需要自建大模型；
某个开源项目是否适合生产环境；
云服务与本地部署哪个成本更低。

内容创作

例如：

深度博客文章；
行业趋势报告；
产品研究报告；
商业分析文章；
带引用的知识型内容。

学习复杂概念

例如：

比较不同经济理论；
分析历史事件；
理解存在争议的科学问题；
梳理一个跨学科主题。

九、哪些情况不需要使用 STORM？

并不是所有问题都需要深度研究。

以下任务通常直接提问即可：

查询一个明确日期；
翻译一段文字；
修正错别字；
进行简单计算；
编写一个基础函数；
查询一个稳定定义；
调整一段文案语气。

如果一个问题只有明确答案，就没有必要模拟多个专家制造无意义的分歧。

STORM 更适合以下特征的问题：

问题本身比较复杂；
存在明显争议；
不同群体立场不同；
需要综合多个来源；
结论会影响重要决策；
需要形成长篇研究报告。

十、使用 AI 深度研究时需要注意什么？

1. 多视角不等于真实专家

AI 模拟的实践者、学者或经济学家，并不是真实专家。

这些角色的作用是帮助展开问题，而不是提供专家资质。

2. 有引用不代表引用正确

AI 可能出现：

链接与结论不匹配；
引用二手报道；
错误理解论文内容；
引用已经过时的数据；
找到同名但无关的资料。

关键来源仍然需要人工打开核验。

3. 共识不一定就是事实

多个 AI 角色可能共享同一训练偏差，因此它们同时认同某个观点，并不能自动证明观点正确。

4. 复杂输出可能掩盖错误

表格、评分、引用和专业术语会让报告看起来更可信，但排版精美不等于证据可靠。

5. 研究结果具有时间限制

涉及技术、市场、法律、价格、公司和政策的信息可能快速变化。

最终报告中应该标明：

检索日期；
数据时间范围；
资料来源；
尚未核实的内容；
研究适用边界。

总结：不要让 AI 只给答案，要让它展示研究过程

传统的 AI 问答通常是：

1
2
3

提出问题
↓
生成答案

STORM 式研究则更接近：

拆解问题
↓
发现不同视角
↓
提出多维度问题
↓
检索外部资料
↓
比较证据与矛盾
↓
形成结构化大纲
↓
生成研究简报
↓
评估结论可信度

两者最大的区别，不是最终文章更长，而是研究过程更加透明。

当一个问题涉及争议、利益、风险或长期决策时，不要急着让 AI 给出确定答案。先让它寻找不同视角、展示矛盾、比较证据，再决定哪些结论值得相信。

AI 深度研究真正有价值的地方，不是替你思考，而是帮助你发现原本没有想到的问题。

项目地址

STORM 在线版属于研究预览，生成的报告仍可能包含错误。涉及医疗、法律、金融、商业投资或其他重要决策时，应进一步核对原始资料，并咨询对应领域的专业人士。

Skills 创建全流程：从需求规划到测试落地，零基础也能完成

Tue, 28 Jul 2026 11:08:00 +0800

很多人第一次接触 Skills 时，会认为它只是一个写了提示词的 Markdown 文件。

实际上，一个真正稳定、可复用的 Skill，更像是一份专门交给 AI 执行的标准作业流程。它不仅要告诉 AI“做什么”，还要说明什么时候启用、按照什么步骤执行、需要读取哪些资料，以及最终应该输出什么结果。

本文将完整梳理 Skills 创建流程，从前期规划、目录初始化、SKILL.md 编写，到验证与实际测试。即使没有开发经验，也可以按照步骤逐步完成。

一、什么是 Skill？

Skill 是一个独立的文件夹，其中包含 AI 完成特定任务所需要的说明、脚本、参考资料和模板资源。

它可以把通用 AI 转变成更适合某项工作的专业助手，例如：

按固定格式撰写产品介绍
根据公司规范回复客户邮件
自动分析 Excel 或 CSV 数据
按统一标准生成网站文章
批量处理图片或 PDF 文件
调用特定 API 完成固定工作流
根据团队规范检查代码

一个 Skill 通常围绕一个明确任务设计，而不是试图解决所有问题。

第一阶段：前期规划

在创建文件之前，先把 Skill 的目标和使用方式规划清楚。

这一步看似没有写代码，却会直接决定 Skill 是否容易触发、执行是否稳定，以及后续是否方便维护。

1. 明确 Skill 的目标

建议从以下四个方面定义目标。

1.1 功能描述

首先说明这个 Skill 具体解决什么问题。

不要只写：

帮助用户处理内容。

这种描述过于宽泛，AI 很难判断应该在什么情况下调用它。

更清晰的写法是：

根据用户提供的原始资料，生成适合个人博客发布的中文 Markdown 文章，并补充标题、文章结构、SEO 关键词、标签和项目地址。

功能描述越具体，后续越容易设计执行流程。

1.2 适用场景

明确用户在什么情况下需要使用这个 Skill。

例如：

用户要求润色个人博客文章
用户提供视频文案，希望整理成教程
用户希望生成可直接复制的 Markdown 内容
用户希望补充 GitHub 项目地址
用户要求文章适合 Google SEO 和 AI 搜索引用

适用场景也是 Skill 判断是否应该触发的重要依据。

1.3 预期输出

提前规定 Skill 完成任务后应该交付什么。

例如：

1. 原文问题分析
2. 建议补充的信息
3. 优化后的文章标题
4. 可直接复制的 Markdown 正文
5. SEO 描述
6. Tags 标签
7. 项目地址

输出格式越明确，多次执行时的结果越稳定。

1.4 限制条件

同时还要说明 Skill 不应该做什么。

例如：

不虚构测试数据
不编造 GitHub Stars 数量
无法确认的信息需要明确标注
不堆砌 SEO 关键词
不在文章中保留明显错别字
不泄露 API Key、密码或个人隐私
未经确认不得执行删除、付款或生产环境修改

限制条件可以减少 AI 自由发挥过度造成的问题。

2. 分析实际需求

目标明确后，需要从用户、技术、性能和兼容性四个维度继续分析。

2.1 用户需求

先判断谁会使用这个 Skill，以及他们会如何提出请求。

建议至少准备 3～5 个真实示例。

例如，创建一个博客文章优化 Skill 时，用户可能会这样说：

`1`	`帮我把这段视频文案整理成博客文章。`

`1`	`重新润色这篇文章，并补充 GitHub 项目地址。`

`1`	`生成可以直接复制到 Hugo 网站中的 Markdown 内容。`

`1`	`让文章更适合 Google SEO 和 AI 搜索引用。`

这些真实表达可以帮助你完善 Skill 的触发描述。

2.2 技术需求

检查 Skill 是否需要额外工具或文件。

常见资源包括：

Python 或 Bash 脚本
API 接口
MCP 服务
浏览器搜索能力
GitHub 项目资料
公司内部文档
Markdown 模板
图片、Logo 或字体
Excel、PDF、Word 处理工具

并不是每个 Skill 都需要脚本。

能够通过清晰文字说明完成的任务，优先写在 SKILL.md 中；只有重复、容易出错或需要固定结果的操作，才更适合使用脚本。

2.3 性能需求

提前考虑执行成本和效率，例如：

是否需要联网搜索
是否会读取大型文件
是否需要处理大量图片
是否会调用付费 API
是否需要批量执行
是否存在较长的运行时间
是否需要限制 Token 消耗

Skill 内容也不宜无限扩张。应只保留 AI 真正需要的规则，把较长的资料放入 references/，需要时再读取。

2.4 兼容性需求

确认 Skill 将在哪些平台或环境中运行，例如：

Codex
Claude Code
GitHub Copilot
Cursor
Gemini CLI
Windows
macOS
Linux
Docker
团队内部 Agent 平台

不同平台对 Skill 的安装路径、元数据和调用方式可能不同，因此不要默认一个 Skill 在所有环境中都能完全通用。

第二阶段：正式创建 Skill

规划完成后，就可以开始建立目录和编写内容。

3. Skill 命名规范

建议使用：

小写英文字母
数字
连字符 -

不要使用：

空格
中文文件夹名
下划线
大写字母
含义不清的缩写

正确示例：

`1`	`blog-content-optimizer`

`1`	`fabric-email-writer`

`1`	`github-project-researcher`

不推荐：

`1`	`My Skill`

`1`	`blog_skill`

新建技能

文件夹名称应该与 SKILL.md 中的 name 保持一致。

4. 使用 Skill Creator 初始化

如果当前环境中已经安装官方 skill-creator，建议优先使用初始化脚本，而不是手动建立所有文件。

标准命令格式：

`1`	`scripts/init_skill.py <skill-name> --path <output-directory>`

例如，将 Skill 创建到 Codex 默认 Skills 目录：

1
2

scripts/init_skill.py my-skill \
  --path "${CODEX_HOME:-$HOME/.codex}/skills"

同时创建 scripts/ 和 references/：

1
2
3

scripts/init_skill.py my-skill \
  --path "${CODEX_HOME:-$HOME/.codex}/skills" \
  --resources scripts,references

同时创建脚本、参考资料和静态资源目录：

1
2
3

scripts/init_skill.py my-skill \
  --path "${CODEX_HOME:-$HOME/.codex}/skills" \
  --resources scripts,references,assets

初始化脚本可以自动生成基础模板，减少目录名称、YAML 格式和必要文件写错的概率。

不同版本的 Skill Creator 所在路径可能不同。实际使用时，应以本机安装目录中的 skill-creator 文件为准。

5. 手动创建 Skill 目录

没有初始化脚本时，也可以手动创建。

Windows PowerShell

mkdir my-skill
cd my-skill

New-Item SKILL.md -ItemType File
mkdir scripts
mkdir references
mkdir assets

tree /F

macOS 或 Linux

mkdir my-skill
cd my-skill

touch SKILL.md
mkdir scripts references assets

tree -a

如果系统没有安装 tree，可以使用：

`1`	`find . -maxdepth 3 -print`

或者：

ls -la

需要注意，scripts/、references/ 和 assets/ 都是可选目录。没有实际用途时，不需要为了结构完整而创建空文件夹。

6. 标准目录结构

一个较完整的 Codex Skill 可以采用以下结构：

my-skill/
├── SKILL.md
├── agents/
│   └── openai.yaml
├── scripts/
├── references/
└── assets/

各目录作用如下。

`SKILL.md`

这是整个 Skill 的核心文件，必须存在。

它负责说明：

Skill 名称
Skill 的用途
什么时候应该触发
应该按照什么流程执行
应该读取哪些资源
最终输出什么结果
有哪些限制条件

文件名必须写成：

`1`	`SKILL.md`

不建议写成：

`1`	`skill.md`

部分系统区分大小写，错误命名可能导致 Skill 无法被识别。

`agents/openai.yaml`

这是 Codex Skill 推荐使用的界面元数据文件，可用于展示：

Skill 显示名称
简短说明
默认提示语
图标或界面相关信息

它主要服务于 Skill 列表和交互界面，不应代替 SKILL.md 中的核心执行规则。

`scripts/`

用于保存可以重复执行的代码，例如：

scripts/
├── clean_markdown.py
├── validate_output.py
└── export_result.py

适合放入脚本的任务通常具备以下特点：

操作步骤固定
需要重复执行
手动生成容易出错
结果必须保持一致
需要调用本地程序或处理文件

新增脚本后，应实际运行测试，不能只确认代码看起来正确。

`references/`

用于保存参考资料，例如：

references/
├── writing-rules.md
├── seo-checklist.md
├── api-documentation.md
└── company-style-guide.md

较长的背景资料不建议全部塞进 SKILL.md。

可以在 SKILL.md 中说明什么时候读取某份参考资料，让 AI 按需加载，从而减少上下文占用。

`assets/`

用于保存最终任务可能使用的静态资源，例如：

assets/
├── logo.png
├── article-template.md
├── report-template.docx
└── website-template/

它适合存放：

图片
图标
Logo
文档模板
网页模板
示例文件
需要复制到输出结果中的资源

`LICENSE` 或 `LICENSE.txt`

如果 Skill 准备公开发布或共享给团队，应明确授权方式。

常见许可证包括：

MIT License
Apache License 2.0
GNU GPL
项目自定义许可证

对于仅在个人电脑内部使用的 Skill，许可证通常不是运行所必需的；但公开到 GitHub 前，建议补充清晰的授权文件。

第三阶段：编写 SKILL.md

7. YAML Frontmatter

SKILL.md 顶部需要包含 YAML 元数据。

基础格式：

---
name: my-skill
description: Explain what this skill does and exactly when it should be used.
---

其中最重要的是 description。

它不仅是介绍文字，也是 AI 判断是否调用这个 Skill 的主要依据。

不推荐：

`1`	`description: 一个非常好用的内容处理工具。`

8. 编写执行流程

SKILL.md 正文应该以明确、可执行的规则为主。

下面是一个简单示例：

---
name: blog-content-optimizer
description: Optimize Chinese blog content into clear, credible and copy-ready Markdown. Use when the user provides rough notes, transcripts or existing articles and asks for rewriting, SEO improvement, GitHub project verification, tags or website publishing content.
---

# Blog Content Optimizer

## Workflow

1. Read the complete source material.
2. Correct spelling, command and terminology errors silently.
3. Identify vague, repetitive or overly promotional statements.
4. Determine what factual information is missing.
5. Verify time-sensitive claims and GitHub project information.
6. Rewrite the article in clear Chinese Markdown.
7. Preserve relevant SEO keywords naturally.
8. Add the verified project address at the end.
9. Generate comma-separated tags.

## Output

Return the following sections:

1. 原文存在的问题
2. 建议补充的信息
3. 中文优化版
4. Tags
5. 项目地址

## Rules

- Do not fabricate facts, statistics, Stars or test results.
- Do not stuff keywords.
- Do not mention spelling corrections in the final article.
- Mark information that cannot be verified.
- Keep headings descriptive and easy to quote.
- Prefer concrete steps and examples over marketing language.

这类写法比长篇介绍更有效，因为每一条都可以直接指导 AI 执行。

第四阶段：验证与测试

9. 运行基础校验

完成 Skill 后，可以使用 Skill Creator 提供的验证脚本检查格式。

`1`	`scripts/quick_validate.py <path/to/skill-folder>`

例如：

`1`	`scripts/quick_validate.py ~/.codex/skills/my-skill`

验证工具通常可以发现：

SKILL.md 缺失
YAML 格式错误
缺少 name
缺少 description
文件夹命名不符合规范
Skill 名称与目录不一致

出现错误后，根据提示修改，再重新运行验证命令。

10. 使用真实任务测试

通过格式验证，并不代表 Skill 已经真正可用。

至少准备 3～5 个测试请求，例如：

`1`	`把下面的视频文案整理成可以发布的 Markdown 教程。`

`1`	`检查这篇文章中的 GitHub 项目是否真实，并补充项目地址。`

`1`	`让文章更适合 Google SEO，但不要堆砌关键词。`

`1`	`只修改错别字，不改变原文语气。`

测试时重点观察：

Skill 是否在正确场景触发
不相关请求是否错误触发
输出结构是否稳定
是否遗漏关键步骤
是否读取了正确的参考资料
是否出现虚构内容
脚本是否能够正常运行
多次执行的结果是否基本一致

11. 根据测试结果持续优化

Skill 通常不会一次完成。

更合理的优化循环是：

实际使用
↓
发现遗漏或错误
↓
定位问题来源
↓
修改 SKILL.md、脚本或参考资料
↓
重新验证
↓
再次使用真实任务测试

例如：

经常没有补充项目地址 → 在工作流程和输出格式中同时增加 GitHub 检查要求。
经常错误触发 → 缩小 description 中的使用范围。
经常无法识别用户表达 → 在 description 中增加常见触发场景。
输出格式不稳定 → 提供固定模板或示例。
重复任务消耗较多 Token → 把固定操作改成脚本。

Skill 的价值并不在于文件数量，而在于它能否让同类任务以更稳定、更可预测的方式重复完成。

哪些情况适合使用 Skill Creator？

1. 创建新的 Skill

当你只有一个需求想法，还没有确定目录、执行步骤和输出结构时，可以让 Skill Creator 帮助完成：

需求梳理
使用场景分析
目录初始化
SKILL.md 草稿
资源规划
验证与测试

2. 优化已有 Skill

如果已有 Skill 经常漏步骤、错误触发或输出不稳定，可以使用 Skill Creator：

优化 description
精简冗余内容
补充测试案例
重新规划脚本和参考资料
比较修改前后的执行结果

3. 团队协作

多人共同维护 Skills 时，Skill Creator 可以帮助团队统一：

目录结构
文件命名
输出格式
开发流程
测试标准
版本维护方式

4. 固定且重复的工作流

例如只需要几个固定命令或固定步骤的任务，也适合封装成 Skill：

项目初始化
文件格式转换
批量重命名
发布前检查
固定格式报告生成

不过，任务越简单，Skill 内容越应该保持精简，不需要为了显得完整而增加大量无用说明。

5. 高度定制的业务任务

当任务依赖公司内部规范、专业资料、固定模板或特殊流程时，Skill 可以将这些知识组织成可复用资源。

例如：

面料报价邮件规范
公司品牌文案规则
内部数据库查询方式
特定 API 调用流程
固定交付文件格式

创建 Skill 时的常见错误

错误一：目标范围过大

例如：

`1`	`帮助用户完成所有办公任务。`

这种 Skill 几乎无法稳定触发，也很难测试。

应该拆分成：

1
2
3

customer-email-writer
invoice-data-checker
weekly-report-generator

错误二：只写功能，不写触发场景

如果 description 没有说明什么时候使用，AI 可能无法正确调用。

错误三：把所有资料都写进 SKILL.md

过长的文件会占用更多上下文。

应该将详细资料拆分到 references/，需要时再读取。

错误四：创建大量无用目录

没有脚本就不需要建立空的 scripts/；没有静态资源也不需要建立 assets/。

错误五：脚本没有实际运行

AI 生成的脚本即使语法看起来正确，也可能存在依赖、路径或参数问题，必须实际执行测试。

错误六：只验证格式，不测试效果

格式正确只能证明 Skill 可以被读取，不能证明它能完成真实任务。

错误七：在文件中写入敏感信息

不要把以下内容直接写入 Skill：

API Key
登录密码
Cookie
私钥
客户隐私数据
生产环境凭据

敏感信息应通过安全的环境变量或密钥管理工具提供。

总结

一个标准的 Skills 创建流程，可以归纳为六个步骤：

明确目标
↓
收集真实使用案例
↓
规划 scripts、references 和 assets
↓
初始化并编写 SKILL.md
↓
运行格式验证和真实任务测试
↓
根据实际结果持续迭代

对于零基础用户来说，最重要的不是一次写出复杂的 Skill，而是先选择一个明确、重复出现的小任务。

只要目标清晰、触发场景明确、输出格式固定，并通过真实任务不断测试优化，就可以逐步建立一套属于自己的 AI 工作流程。

Prompt Optimizer：把模糊想法变成可测试、可复用的 AI 提示词

Mon, 27 Jul 2026 22:24:00 +0800

写 AI 提示词时没有思路，很多人的第一反应是继续堆背景、加角色、补格式。

结果往往是提示词越来越长，AI 的回答却不一定更准确。

最近我发现了一个比较实用的开源项目：Prompt Optimizer。它不是单纯把一句话扩写成一大段，而是提供了一套完整的提示词优化流程，包括：

优化原始提示词
测试实际输出
对比优化前后的结果
根据反馈继续迭代
收藏并复用稳定版本

项目在 GitHub 上已经获得超过 3 万个 Star，适合经常使用 ChatGPT、Claude、Gemini、DeepSeek、Grok 等 AI 模型的人。

Prompt Optimizer 是什么？

Prompt Optimizer 是一款开源的 AI 提示词优化工具。

你只需要输入一个比较粗糙的需求，例如：

帮我写一篇介绍网站速度优化的文章。

它会尝试补充任务目标、读者对象、内容结构、输出格式和限制条件，将原本模糊的想法整理成更容易被 AI 理解和执行的提示词。

它真正有价值的地方，不是把提示词写得更长，而是让提示词变得：

目标更明确
条件更完整
输出更可控
测试结果更容易比较
后续更方便重复使用

它和普通提示词扩写工具有什么区别？

普通的提示词生成器通常只完成一次改写。

Prompt Optimizer 更接近一个提示词工作台：你可以优化、测试、比较，再根据结果继续调整。

1. 支持两种提示词优化模式

它可以分别处理：

系统提示词：定义 AI 的身份、长期规则、行为边界和输出标准。
用户提示词：处理某一次具体任务，例如写文章、分析数据、生成代码或制作图片。

这两种提示词的作用不同，分开优化比简单混在一起更容易控制最终结果。

2. 可以对比优化前后的回答

提示词看起来更专业，不代表实际效果一定更好。

Prompt Optimizer 支持分析、单结果评估和多结果对比。你可以使用同一个问题分别测试原始提示词和优化后的提示词，再观察以下变化：

回答是否更准确
结构是否更清晰
是否减少无关内容
是否遵守输出格式
是否真正解决了任务

这种方式比凭感觉判断提示词质量更可靠。

3. 支持多轮迭代

第一次优化不满意，可以继续提出修改方向，例如：

内容太长，需要精简
语言太像 AI
缺少具体示例
输出格式不稳定
需要增加限制条件
需要适配某个特定模型

通过多轮修改，可以逐步得到更符合实际工作需求的提示词。

不只是文字提示词

Prompt Optimizer 也支持图片生成相关工作流，包括：

文生图
图生图
多图生成
参考图风格迁移
图片提示词优化
图片生成结果预览

例如你只输入：

一座漂浮在夜空中的图书馆。

优化后可以进一步明确：

主体位置
镜头视角
空间层次
光线方向
色彩氛围
画面风格
主体与背景关系
不希望出现的元素

这样做不能保证每一次都生成完美图片，但可以减少模型自由发挥带来的随机性，让画面更接近预期。

支持哪些 AI 模型？

根据项目文档，Prompt Optimizer 已支持或兼容多种主流模型和服务，包括：

OpenAI
Gemini
DeepSeek
Grok
智谱 AI
MiniMax
SiliconFlow
Ollama 等本地模型

不同模型对提示词的理解方式并不完全相同，因此实际使用时，最好固定模型进行测试，不要只优化一次就直接在所有模型中通用。

四种使用方式

Prompt Optimizer 提供了多种使用方式。

在线版

适合第一次体验，不需要安装程序。

项目采用纯前端架构，数据主要保存在浏览器本地，并直接与配置的 AI 服务商交互。

使用在线版时仍需注意：不要把公司机密、客户资料、账号密码或未公开代码直接发送给第三方 AI 模型。

桌面版

桌面版适合长期使用，也更方便连接本地模型或存在跨域限制的 API。

项目提供 Windows、macOS 和 Linux 对应的安装包或压缩包，具体版本以 GitHub Releases 页面为准。

Chrome 插件

Chrome 插件适合在浏览器中直接调用提示词优化功能，减少在多个页面之间复制和切换。

Docker 部署

熟悉 Docker 的用户可以将 Prompt Optimizer 部署到自己的服务器或 NAS 中，方便自己使用或在团队内部共享。

私有部署并不等于绝对安全。API Key、访问密码、服务器权限和日志记录仍需要正确配置。

提示词也可以成为可复用资产

很多人写完提示词后就随手丢在聊天记录里，下次遇到相同任务又要重新写一遍。

Prompt Optimizer 支持收藏、版本历史、示例保存和来源绑定，可以将经过验证的提示词整理成自己的提示词库。

例如可以分别保存：

SEO 文章写作提示词
商务邮件翻译提示词
GitHub 项目分析提示词
商品测评提示词
代码审查提示词
网站封面图提示词
客服回复提示词

当提示词经过多次测试并证明稳定后，它就不再是一段临时文字，而是一套可以重复执行的工作流程。

一个简单的使用方法

第一次使用时，可以按照下面的步骤操作：

输入原始需求，不需要一开始就写得很完整。
选择系统提示词或用户提示词优化模式。
检查优化结果是否准确表达了你的真实目的。
使用同一个模型测试原始版和优化版。
对比准确性、完整性、格式和冗余程度。
根据测试结果继续优化。
将稳定版本收藏并命名。
保存一个实际输入与输出示例，方便以后复现。

哪些人适合使用？

Prompt Optimizer 比较适合以下用户：

不熟悉提示词工程的新手
经常使用多个 AI 模型的人
需要稳定生成文章、邮件或代码的人
需要制作 AI 图片提示词的人
希望沉淀团队提示词模板的人
想对比不同提示词实际效果的人
希望把提示词作为工作资产管理的人

使用时需要注意什么？

Prompt Optimizer 可以提高提示词的清晰度，但它不能替代事实核查和人工判断。

使用时建议注意以下几点：

提示词更长不代表更好。 多余背景和重复规则可能增加 Token 消耗，也可能让模型忽略真正重要的要求。
优化后必须测试。 不要只看文字是否专业，应检查实际输出是否改善。
不同模型需要分别验证。 在一个模型上表现良好的提示词，不一定适合所有模型。
不要提交敏感信息。 客户资料、商业机密、密码、私有代码和个人隐私应先脱敏。
保留版本和示例。 只有保存模型、参数、输入和输出示例，后续结果才更容易复现。

总结

Prompt Optimizer 的核心价值，不是自动帮你写出一段看起来复杂的提示词，而是将提示词从一次性的聊天输入，变成一套可以优化、测试、比较和复用的工作资产。

对于偶尔使用 AI 的用户，它可以降低提示词写作门槛。

对于高频使用 AI 的个人或团队，它更适合用来建立稳定的提示词库和测试流程。

真正值得保留的提示词，不是文字最长的那一个，而是经过实际任务验证后，能够稳定得到理想结果的那一个。

项目地址

GitHub：https://github.com/linshenkx/prompt-optimizer
在线版：https://prompt.always200.com
项目文档：https://docs.always200.com

提示：GitHub Star、支持的模型和功能版本会持续变化，请以项目仓库和最新 Release 说明为准。

Codex 最近变“啰嗦”了？在 AGENTS.md 加上这句提示词试试

Mon, 27 Jul 2026 22:04:00 +0800

最近使用 Codex 时，你可能会遇到这样的情况：

以前只需要一句话，Codex 就能直接修改代码、运行测试并完成任务；现在却经常输出大量过程说明，需要反复确认和引导，真正的代码修改反而变慢了。

遇到这种情况，可以尝试在 Codex 的 AGENTS.md 文件中加入下面这句指令：

`1`	`DO NOT send optional commentary.`

它的意思很简单：

不要发送非必要的过程说明。

这句提示词能解决什么问题？

Codex 在执行任务时，可能会主动输出以下内容：

接下来准备检查哪些文件
为什么选择某种实现方式
还可以继续做哪些可选优化
是否需要运行额外测试
大量并非必须的解释和总结

这些内容并不一定有错，但在需求已经非常明确时，过多的过程播报会让交互显得拖沓，也会占用额外的输出 Token。

加入这条指令后，Codex 通常会更倾向于：

直接读取代码并开始修改
减少不必要的进度说明
只保留与结果有关的信息
缩短最终回复
降低无效输出带来的 Token 消耗

简单理解就是：

需求明确时，直接做事，不要边做边反复解释。

正确添加到哪个文件？

正确的文件名是：

`1`	`AGENTS.md`

Codex 官方支持通过 AGENTS.md 为项目添加长期指令。每次开始任务前，Codex 会读取适用范围内的规则，并将其作为项目上下文的一部分。

方法一：只对当前项目生效

在项目根目录创建：

你的项目/
├── AGENTS.md
├── package.json
├── src/
└── README.md

然后在 AGENTS.md 中写入：

1
2
3

# Codex Instructions

DO NOT send optional commentary.

这种方式只会影响当前项目，适合先测试实际效果。

方法二：让所有项目默认生效

在 Codex 的全局目录中创建：

`1`	`~/.codex/AGENTS.md`

Windows 通常对应：

`1`	`C:\Users\你的用户名\.codex\AGENTS.md`

写入：

1
2
3

# Global Codex Instructions

DO NOT send optional commentary.

全局文件适合保存个人长期偏好，例如回复风格、代码习惯和默认工作方式。项目目录中的 AGENTS.md 则更适合保存当前仓库的技术规范。Codex 会按照目录层级加载这些指令，距离当前工作目录更近的规则优先级更高。

更实用的完整写法

只写一句话虽然简单，但容易被理解成“完全不要解释”。为了避免 Codex 省略必要的错误信息，可以改成下面这种更明确的版本：

# Response Style

DO NOT send optional commentary.

Start working directly when the task is clear.
Do not provide routine progress updates.
Do not explain self-evident code.
Do not add unnecessary comments to generated code.
Report only blockers, important decisions, test results, and the final outcome.

对应的中文含义是：

任务明确时直接开始执行
不要发送常规进度播报
不要解释一眼就能看懂的代码
不要生成没有实际价值的代码注释
只报告阻塞问题、重要决策、测试结果和最终结果

这种写法比单独一句 DO NOT send optional commentary. 更稳定，因为它明确规定了哪些内容可以省略，哪些关键信息仍然必须保留。

它为什么可能让 Codex 感觉更快？

这条指令并不会直接提升模型的推理能力，也不会真正修改 Codex 模型。

它主要减少的是可见输出中的冗余内容。

对于需要多次读取文件、调用工具和修改代码的任务，Codex 可能会在工具调用之间发送进度说明。减少这些非必要文本后，交互过程会更紧凑，用户感受到的等待时间和 Token 消耗也可能有所下降。

OpenAI 的 Codex 提示指南同样建议：代码本身足够清楚时，不要添加重复解释功能的注释；只有复杂逻辑确实需要说明时，才使用简短注释。

这条指令不能解决哪些问题？

需要注意，DO NOT send optional commentary. 并不是官方发布的“Codex 降质修复代码”。

它无法直接解决以下问题：

项目上下文过长或包含过时信息
AGENTS.md 中存在互相冲突的规则
当前模型或推理强度选择不合适
任务描述过于模糊
依赖、测试环境或项目本身存在问题
Codex 没有获得读取或执行命令所需的权限

目前可以确认的是，这句话已经出现在 Codex 用户反馈和部分开源项目的 AGENTS.md 中，但相关效果主要来自用户实践，并不代表 OpenAI 官方承诺它能够恢复模型质量。

使用建议

建议先把它添加到某一个项目根目录的 AGENTS.md 中，而不是直接加入全局配置。

测试几次真实任务后，重点观察：

Codex 是否减少了无意义的过程说明；
是否仍然能够报告报错和测试结果；
是否出现回复过于简略、遗漏重要信息的情况；
实际代码质量有没有改善。

如果发现 Codex 连关键问题也不再说明，可以将规则改成：

`1`	`Avoid optional commentary, but always report blockers, failed checks, security risks, and important implementation decisions.`

这样既能减少“唠嗑”，又不会隐藏真正需要关注的信息。

总结

DO NOT send optional commentary. 的核心作用，不是让 Codex 突然变得更聪明，而是限制它输出不必要的过程说明。

对于需求明确、希望 Codex 直接修改代码的用户，这条规则可能带来三个实际变化：

回复更短
过程更直接
可见输出消耗的 Token 更少

如果 Codex 最近只是变得啰嗦、频繁汇报进度，这条指令值得尝试；如果问题是代码错误增多、理解需求失败或任务无法完成，则还需要继续检查模型设置、项目上下文、权限以及 AGENTS.md 中是否存在冲突规则。

项目地址与参考资料

UI/UX Pro Max：让 AI 生成的界面摆脱模板感

Mon, 27 Jul 2026 21:55:00 +0800

使用 AI 编程工具生成网页时，很多人都会遇到同一个问题：

代码可以运行，但界面一眼就能看出是 AI 做的。

页面通常拥有相似的渐变背景、圆角卡片、超大标题和玻璃效果。无论开发的是企业官网、后台管理系统，还是医疗、金融类产品，AI 都可能套用相近的视觉风格。

这种问题并不完全是 AI 不会写前端，而是它在生成代码之前，缺少一套针对具体业务场景的设计判断。

开源项目 UI/UX Pro Max，就是为了解决这个问题而出现的。

UI/UX Pro Max 是什么？

UI/UX Pro Max 是一个面向 AI 编程助手的设计智能 Skill。

它不是一套固定的网页模板，也不是简单收集几十种配色方案，而是将 UI 风格、颜色、字体、用户体验规范、图表设计和技术栈规则整理成一个可检索的设计知识库。

当 AI 接到页面开发任务后，可以先根据产品类型、行业属性和使用场景检索合适的设计规则，再生成完整的设计系统，最后进入代码实现阶段。

官方项目资料显示，目前的规则库包含：

84 种 UI 风格
192 套配色方案
74 组字体搭配
98 条 UX 指南
25 种图表类型
22 种技术栈规则

项目采用 MIT License，并支持 Claude Code、Cursor、Windsurf、GitHub Copilot、Codex CLI、Gemini CLI、OpenCode 等多种 AI 编程助手。

AI 生成的 UI 为什么容易出现“模板感”？

普通 AI 编程助手接到这样的需求：

帮我设计一个现代化的 SaaS 产品首页。

它往往会直接进入代码生成阶段。

由于缺少行业、用户和品牌信息，AI 只能调用训练数据中出现频率较高的设计模式，例如：

蓝紫色渐变背景
大量圆角卡片
玻璃拟态效果
居中的超大标题
三列功能介绍
缺少差异化的信息架构
动效很多，但没有明确作用

这些设计本身并不一定错误。

真正的问题是，AI 没有先判断：

这是什么类型的产品？
页面主要面向谁？
用户进入页面后最需要完成什么任务？
这个行业适合什么视觉语言？
哪些设计会削弱专业感和可信度？
当前技术栈适合采用哪些组件和交互方式？

当所有项目都使用相同的设计套路时，页面自然会出现明显的“AI 味”。

UI/UX Pro Max 如何改善 AI 生成界面？

UI/UX Pro Max 的核心价值，不是为 AI 增加更多模板，而是改变 AI 的工作顺序。

普通工作流程通常是：

用户提出需求
→ AI 直接写代码
→ 生成页面
→ 再反复修改样式

接入 UI/UX Pro Max 后，流程会变成：

用户提出需求
→ 分析产品类型与使用场景
→ 检索设计规则
→ 生成设计系统
→ 编写页面代码
→ 检查常见 UI/UX 反模式

官方说明中也明确列出了这套过程：AI 会先理解需求，生成设计系统，推荐合适的样式、颜色和字体，再进行代码实现，并在交付前检查常见的 UI/UX 问题。

换句话说，它试图让 AI 从“直接写页面”，转变为：

先完成设计判断，再进行前端实现。

它能提供哪些设计判断？

1. 页面结构与用户流程

不同类型的产品，需要不同的信息结构。

例如：

SaaS 首页需要突出价值主张、功能、使用案例和转化入口
电商页面需要突出商品、价格、评价和购买路径
后台系统需要重视信息密度、筛选效率和操作反馈
医疗产品需要强调可信度、清晰度和无障碍体验
金融产品需要避免轻浮视觉，并突出安全感和数据准确性

UI/UX Pro Max 会根据产品类型，帮助 AI 选择更合理的页面结构，而不是机械套用统一模板。

2. UI 风格、配色与字体

项目内置了多种 UI 风格、配色方案和字体组合。

AI 可以根据行业和品牌定位，选择更适合的视觉语言。例如：

科技产品可采用克制、清晰的现代风格
奢侈品网站可使用更高留白比例与精细字体
儿童产品可使用更友好、活泼的颜色
企业后台应优先保证清晰度和信息效率
医疗和金融产品应避免过于娱乐化的视觉效果

重点并不是“哪套颜色更漂亮”，而是“哪套设计更符合业务场景”。

3. 交互规范与动效建议

AI 很容易为了让页面看起来高级，而加入过多动画。

但真正专业的动效，应该帮助用户理解状态变化，例如：

按钮点击后的反馈
表单提交中的加载状态
页面切换时的层级变化
错误信息出现的位置
弹窗打开与关闭的过渡
数据刷新后的视觉提示

UI/UX Pro Max 会引导 AI 使用有明确目的的动效，而不是为了炫技而增加动画。

4. 行业规则与设计反模式

这个项目还会检查一些常见的 UI/UX 问题，例如：

正文文字对比度过低
按钮颜色与背景接近
点击区域过小
页面缺少加载状态
表单错误提示不清楚
移动端布局没有适配
图标风格不统一
重要操作缺少确认机制
动画时间过长
内容层级不明确

对于医疗、金融、企业服务等需要建立信任的行业，这类检查往往比增加视觉特效更重要。

支持哪些前端技术栈？

UI/UX Pro Max 不只提供通用设计建议，还包含针对不同开发框架的规则。

官方列出的技术栈包括：

类型	支持的技术栈
Web	HTML、Tailwind CSS
React 生态	React、Next.js、shadcn/ui
Vue 生态	Vue、Nuxt.js、Nuxt UI
其他 Web 框架	Angular、Svelte、Astro、Three.js
PHP	Laravel、Blade、Livewire、Inertia.js
移动端	SwiftUI、Jetpack Compose
跨平台	React Native、Flutter
桌面端	JavaFX、WPF、WinUI 3、Avalonia 等

没有指定技术栈时，项目默认可以按照 HTML 和 Tailwind CSS 提供建议。

UI/UX Pro Max 安装方法

环境要求

安装前需要准备：

Node.js 与 npm
Python 3.x
已安装并可以正常使用的 AI 编程助手

项目中的设计搜索脚本需要 Python 3.x，但只使用 Python 标准库，不会额外安装依赖，也不需要联网运行。

第一步：安装命令行工具

`1`	`npm install -g ui-ux-pro-max-cli`

需要注意：

当前 npm 包名称是 ui-ux-pro-max-cli
安装完成后使用的命令是 uipro
旧的 uipro-cli 包已经过时，不建议继续使用

不想进行全局安装，也可以直接使用：

`1`	`npx ui-ux-pro-max-cli init --ai claude`

第二步：进入项目目录

`1`	`cd /path/to/your/project`

Windows 用户可以使用自己的实际项目路径，例如：

`1`	`cd D:\Projects\my-web`

第三步：为 AI 助手初始化

Codex CLI

`1`	`uipro init --ai codex`

Claude Code

`1`	`uipro init --ai claude`

Cursor

`1`	`uipro init --ai cursor`

Windsurf

`1`	`uipro init --ai windsurf`

Gemini CLI

`1`	`uipro init --ai gemini`

同时安装到所有支持的平台

`1`	`uipro init --ai all`

官方 CLI 还支持 GitHub Copilot、Kiro、Roo Code、Qoder、OpenCode、Continue、CodeBuddy、Warp、Augment 等工具。

安装后如何使用？

对于支持 Skill 自动触发的 AI 助手，安装完成后通常不需要记忆复杂命令。

可以直接输入类似需求：

请使用 UI/UX Pro Max，为一家面向欧洲客户的纺织品贸易公司设计官网首页。

先分析目标客户、品牌定位和用户访问目的，再输出完整设计系统，包括：

1. 页面信息架构
2. 主色与辅助色
3. 字体与字号层级
4. 栅格与间距规则
5. 按钮、卡片和表单规范
6. 响应式布局方案
7. 动效建议
8. 需要避免的设计反模式

设计系统确认后，再使用 Next.js、Tailwind CSS 和 shadcn/ui 编写代码。

相比只说“帮我做一个高级官网”，这样的提示词提供了更明确的业务信息，也更容易发挥 UI/UX Pro Max 的价值。

一个更实用的使用思路

在实际项目中，可以把 UI/UX Pro Max 分成三个阶段使用。

阶段一：生成设计系统

先让 AI 输出：

产品类型
目标用户
页面目标
信息架构
颜色系统
字体系统
间距系统
组件规范
动效规则
无障碍要求
避坑清单

阶段二：生成页面代码

设计规则确认后，再让 AI 编写：

首页
登录页
仪表盘
产品详情页
表单页面
移动端页面

这样可以减少不同页面之间颜色、字体、按钮和间距不一致的问题。

阶段三：检查已有页面

它也可以用于审核现有项目。

例如：

请使用 UI/UX Pro Max 检查当前页面。

重点检查：

- 信息层级是否清楚
- 配色对比度是否合格
- 字体和间距是否统一
- 移动端是否容易操作
- 表单是否有完整反馈
- 是否存在过度设计
- 是否有明显的 AI 模板感

请先列出问题和修改建议，再修改代码。

使用时需要注意什么？

UI/UX Pro Max 可以改善 AI 的设计判断，但它不能完全替代产品经理和专业设计师。

它无法自动知道：

企业真实的品牌规范
用户调研结果
产品的核心商业目标
哪些功能最影响转化
客户所在市场的审美差异
企业内部的合规要求

因此，在向 AI 提需求时，仍然需要补充具体信息。

相比下面这种模糊表达：

`1`	`帮我设计一个高级、现代、科技感的网站。`

更推荐这样描述：

1
2
3

为一家面向欧洲中高端男装品牌的面料供应商设计官网。

目标用户是品牌采购经理和设计师，页面需要突出面料开发能力、产品分类、认证信息、合作流程和联系方式。整体应专业、克制、有纺织行业质感，避免蓝紫渐变、玻璃拟态、过度动画和互联网 SaaS 模板风格。

输入的信息越具体，AI 越容易生成符合真实业务需求的界面。

总结

UI/UX Pro Max 解决的并不是“AI 不会写 CSS”，而是 AI 在编写前端代码之前，往往没有进行足够的设计分析。

它通过可检索的 UI/UX 知识库，把设计判断前置到代码生成之前，使 AI 能够按照下面的流程工作：

理解业务
→ 分析用户
→ 建立设计系统
→ 选择技术方案
→ 编写代码
→ 检查设计问题

对于没有专职设计师的个人开发者、小团队和 AI 编程用户来说，这种工作方式可以减少反复修改，也能让不同页面保持更统一的视觉和交互规范。

它不会让 AI 自动变成资深设计师，但能明显降低 AI 直接套用通用模板的概率。

项目信息

项目名称：UI/UX Pro Max
开发者：NextLevelBuilder
开源协议：MIT License
GitHub 项目：nextlevelbuilder/ui-ux-pro-max-skill

Headroom：最高减少 92% Token，用 AI 编程时别再把钱浪费在无效上下文上

Mon, 27 Jul 2026 20:09:00 +0800

使用 Claude Code、Codex、Cursor 等 AI 编程工具时，真正消耗 Token 的往往不只是你输入的提示词。

代码搜索结果、终端日志、报错堆栈、GitHub Issue、历史对话和 RAG 检索内容，都会被不断塞进上下文。随着任务持续进行，上下文越来越长，每次请求的成本和等待时间也会随之增加。

最近发现的开源项目 Headroom，就是专门解决这个问题的。

它会在日志、代码、文件和工具输出发送给大模型之前，先识别内容类型并压缩其中的重复信息和低价值内容，让模型尽量只接收真正需要的信息。

根据项目公开测试，部分场景可以减少约 47%—92% 的输入 Token。

Headroom 是什么？

Headroom 是一个面向 AI Agent 和 AI 编程工具的上下文压缩层。

简单理解，它位于 AI 工具与大模型 API 之间：

Claude Code / Codex / Cursor
            ↓
         Headroom
     压缩日志、代码和历史上下文
            ↓
   OpenAI / Anthropic 等模型

它并不是简单粗暴地删除历史消息，而是根据内容类型选择不同的压缩方式。

例如：

JSON 数据使用结构化压缩
源代码按照 AST 语法结构处理
普通文本使用专门的压缩模型
重复日志、无关字段和冗余搜索结果会被优先精简
原始内容可保存在本地，需要时仍可重新获取

Headroom 默认在本地运行，项目说明中表示，处理的数据可以保留在本机，而不需要额外上传到第三方压缩服务。

实际能节省多少 Token？

Headroom 项目给出了几组真实 Agent 工作负载测试数据：

使用场景	压缩前	压缩后	Token 减少
代码搜索，返回 100 条结果	17,765	1,408	92%
SRE 事故日志排查	65,694	5,118	92%
GitHub Issue 分类	54,174	14,761	73%
大型代码库探索	78,502	41,254	47%

这组数据说明，Headroom 最适合处理大量结构化数据、搜索结果和重复日志。

如果只是几句话的简单问答，压缩空间通常不会特别明显；但在大型代码仓库、持续调试或多 Agent 工作流中，每次节省的 Token 会不断累积。

压缩后会不会影响回答质量？

这是使用上下文压缩工具时最需要关注的问题。

Headroom 项目公开了 GSM8K、TruthfulQA、SQuAD v2 和 BFCL 等测试结果：

测试项目	原始结果	使用 Headroom	变化
GSM8K 数学推理	0.870	0.870	无变化
TruthfulQA 事实问答	0.530	0.560	小幅提升
SQuAD v2 问答	—	97%	19% 压缩率
BFCL 工具调用	—	97%	32% 压缩率

从项目公布的数据看，压缩后没有出现明显的准确率下降，部分测试结果甚至略有提高。

不过需要注意，这些结果主要来自项目方自己的测试环境，并不能代表所有代码库和业务场景。更稳妥的做法，是先在自己的项目中运行一段时间，对比压缩前后的回答质量和 Token 消耗，再决定是否长期启用。

Headroom 支持哪些 AI 编程工具？

Headroom 已经适配多种常见 AI 编程工具，包括：

Claude Code
OpenAI Codex
Cursor
Aider
GitHub Copilot CLI
OpenCode
Cline
Continue
Goose
OpenHands
Grok CLI
Kimi CLI

对于 Claude Code、Codex 和 Aider 等工具，可以直接通过 headroom wrap 启动。

Cursor 目前主要采用手动配置代理地址的方式接入。

此外，Headroom 也支持 Python、TypeScript、LangChain、Agno、LiteLLM、Vercel AI SDK 和 MCP 客户端，适合接入已有的 AI 应用或 Agent 系统。

最简单的安装方法

Headroom 要求 Python 3.10 或以上版本。

推荐使用 uv 进行隔离安装：

`1`	`uv tool install --python 3.13 "headroom-ai[all]"`

也可以直接使用 pip：

`1`	`pip install "headroom-ai[all]"`

安装完成后检查版本：

`1`	`headroom --version`

需要注意，npm 版本只是 TypeScript SDK，并不包含 headroom 命令行工具：

`1`	`npm install headroom-ai`

因此，想直接使用 headroom wrap、代理服务或 MCP 功能，应该优先安装 Python 版本。

在 Claude Code 中使用

安装完成后执行：

`1`	`headroom wrap claude`

Headroom 会启动本地代理，并通过代理启动 Claude Code。

之后，Claude Code 读取代码、运行命令或分析日志时，相关上下文会先经过 Headroom 处理，再发送给模型。

可以使用以下命令检查运行状态：

`1`	`headroom doctor`

查看压缩性能：

`1`	`headroom perf`

打开节省统计面板：

`1`	`headroom dashboard`

在 Codex 中使用

Codex 可以通过下面的命令启动：

`1`	`headroom wrap codex`

如果 Codex 无法识别终端里的 headroom 命令，可以先查询完整路径：

`1`	`command -v headroom`

然后把返回的绝对路径写入 Codex 的 MCP 配置：

1
2
3

[mcp_servers.headroom]
command = "/你的绝对路径/headroom"
args = ["mcp", "serve"]

这种情况通常不是 Headroom 安装失败，而是 Codex 启动时没有继承当前终端的 PATH 环境变量。

跨 Agent 共享记忆

Headroom 不只是压缩工具，还提供跨 Agent 共享上下文的能力。

例如，你可以让 Claude Code 和 Codex 使用同一个本地记忆存储：

1
2

headroom wrap claude --memory
headroom wrap codex --memory

这样，在 Claude Code 中已经分析过的项目内容，可以被压缩、去重后继续提供给 Codex 使用，减少不同 AI 工具重复读取同一批文件。

Headroom 还提供 headroom learn 功能，可以分析失败的历史会话，并把修正经验写入：

CLAUDE.local.md
CLAUDE.md
AGENTS.md
GEMINI.md
GROK.md

这类功能适合长期维护同一个代码库，但自动生成的规则仍然需要人工检查，避免错误经验被持续复用。

Headroom 适合哪些人？

Headroom 更适合以下场景：

经常使用 Claude Code、Codex 或 Cursor
需要分析大量终端日志和报错信息
经常进行大型代码库搜索
使用 API 按 Token 付费
同时使用多个 AI Agent
RAG 检索结果较长且重复内容较多
希望降低上下文成本和请求延迟

下面这些情况则不一定需要安装：

只是偶尔使用网页版 AI 聊天
每次任务都很短，上下文内容很少
使用的环境不允许启动本地代理
已经完全依赖模型厂商自带的上下文压缩
项目涉及敏感业务，但尚未完成安全审查

使用前需要注意什么？

1. 最高 92% 不代表每次都能省 92%

92% 是代码搜索和事故排查等特定测试场景的数据。

根据任务类型不同，实际压缩效果可能只有 20%、40%，也可能在结构化日志中达到更高比例。

2. 先在测试项目中验证

代码上下文可能包含函数签名、错误细节、配置字段和依赖版本。

即使 Headroom 支持可逆压缩，也建议先在非关键项目中测试，确认不会遗漏影响判断的重要信息。

3. 本地运行不等于没有安全风险

Headroom 会位于 AI 工具与模型服务之间，能够接触请求内容。

在公司项目或敏感代码环境中使用前，应检查项目源码、依赖、日志保存方式和代理配置。

4. 定期查看节省数据

可以通过以下命令检查实际收益：

1
2

headroom perf
headroom dashboard

不要只因为项目宣传中的最高数字就长期启用。真正有价值的是，它在你的工作流中能否稳定降低 Token，同时保持结果可靠。

总结

Headroom 解决的不是“提示词写得不够好”，而是 AI Agent 工作过程中产生了太多无效上下文。

代码搜索结果、构建日志、历史对话、RAG 数据和工具返回内容，会不断占用上下文窗口，也会增加 API 成本。

Headroom 在这些内容进入模型前进行结构化压缩，并提供可逆内容检索、跨 Agent 记忆和失败经验学习等功能。对于频繁使用 Claude Code、Codex、Cursor 或其他 AI 编程工具的人，它确实值得测试。

但更准确的说法不是“安装后一定节省 92%”，而是：

在日志、搜索结果和大型代码库等高冗余场景中，Headroom 有机会显著减少 Token；最终效果应以自己的项目测试结果为准。

项目地址

GitHub：https://github.com/headroomlabs-ai/headroom
开源协议：Apache License 2.0
当前 GitHub Stars：约 62.7K，数据会持续变化

Book to Skill：把一本书变成 AI 可以反复调用的知识工具

Mon, 27 Jul 2026 19:55:00 +0800

很多人用 AI 阅读一本书时，通常只会做两件事：

总结全书内容
提炼重点和金句

这种方式可以帮助我们快速了解一本书，却很难真正把书里的方法应用到工作中。

Book to Skill 提供了另一种思路：把 PDF、EPUB、DOCX、Markdown 等文档转换成结构化的 Agent Skill，让 AI 不只是“读过这本书”，而是能够在后续任务中调用书里的框架、原则和方法，帮助你分析问题、检查方案或生成内容。

简单来说，它不是把一本书压缩成一篇摘要，而是把一本书整理成一套可以反复使用的 AI 知识工具。

Book to Skill 是什么？

Book to Skill 是一个开源 Agent Skill，主要用于把书籍、技术文档或一组资料转换成结构化 Skill。

它会从原始文档中提取：

核心框架和思维模型
可以直接执行的方法
决策规则
常见错误和反模式
重要概念与术语
各章节的关键知识
快速查询用的速查表

生成完成后，AI 可以根据当前任务按需读取对应章节，而不是每次都把整本书重新放进上下文。

这意味着，你以后不必反复翻阅几十页甚至几百页的 PDF，也不需要每次重新向 AI 解释这本书讲了什么。

它和普通的 AI 读书总结有什么区别？

普通的 AI 总结通常只能回答：

这本书主要讲了什么？

Book to Skill 更关注的是：

这本书里的方法，应该在什么情况下使用？

例如，一本内容创作类书籍被转换成 Skill 后，你可以让 AI：

根据书中的方法策划短视频选题
设计视频标题和封面文案
检查口播脚本的开头是否足够吸引人
分析内容节奏和信息密度
判断脚本是否存在留存问题
按照书中的标准重写脚本
查询某个概念出自哪个章节

它输出的不是一份看完就放在一边的读书笔记，而是一套能够参与实际工作的知识系统。

Book to Skill 会生成哪些文件？

将一本书转换完成后，通常会得到类似下面的文件结构：

your-book-skill/
├── SKILL.md
├── glossary.md
├── patterns.md
├── cheatsheet.md
└── chapters/
    ├── ch01-introduction.md
    ├── ch02-framework.md
    ├── ch03-methods.md
    └── ...

这些文件分别承担不同作用：

文件	主要用途
`SKILL.md`	保存核心思维模型、使用说明和章节索引
`chapters/`	按章节保存详细知识，需要时再读取
`glossary.md`	整理书中的重要术语和定义
`patterns.md`	汇总技巧、方法、流程和常见模式
`cheatsheet.md`	保存决策规则和快速参考信息

这种结构比单独生成一篇长摘要更实用。

AI 在处理具体问题时，只需要加载相关章节，不必一次把整本书全部塞进上下文，也能减少无关内容对回答的干扰。

支持哪些文档格式？

Book to Skill 当前支持多种常见文档格式，包括：

PDF
EPUB
DOCX
TXT
Markdown
HTML
RTF
reStructuredText
AsciiDoc
MOBI
AZW / AZW3

除了单本书，它还可以处理整个文件夹、多个文档或符合特定规则的一组文件。

因此，它不仅适合处理电子书，也可以用来整理：

企业内部操作手册
品牌规范
产品文档
技术资料
API 说明
行业研究报告
论文与个人笔记
培训教材
项目知识库

只要这些资料是你经常需要查询和使用的，就可以考虑将它们整理成 Skill。

如何安装 Book to Skill？

安装到 Claude Code

在终端中执行：

`1`	`git clone https://github.com/virgiliojr94/book-to-skill.git ~/.claude/skills/book-to-skill`

安装完成后，重新启动 Claude Code，或让它重新加载 Skills。

安装到 GitHub Copilot CLI

`1`	`git clone https://github.com/virgiliojr94/book-to-skill.git ~/.copilot/skills/book-to-skill`

然后在 Copilot CLI 会话中执行：

1
2

/skills reload
/skills info book-to-skill

安装到通用 Agent Skills 目录

`1`	`git clone https://github.com/virgiliojr94/book-to-skill.git ~/.agents/skills/book-to-skill`

这个目录可用于部分兼容开放 Agent Skills 规范的工具。

需要注意的是，不同 AI 编程工具对 Skills 的目录、调用命令和兼容程度可能不同。官方仓库当前明确说明支持 Claude Code、GitHub Copilot CLI 和 Amp。其他工具能否直接使用，应以对应工具的 Skills 文档为准。

如何把一本书转换成 Skill？

假设电脑中有一本书：

`1`	`~/books/content-guide.pdf`

可以执行：

`1`	`/book-to-skill ~/books/content-guide.pdf`

也可以在命令后指定生成的 Skill 名称：

`1`	`/book-to-skill ~/books/content-guide.pdf content-creator-guide`

如果需要把多份资料合并成一个 Skill，可以执行：

`1`	`/book-to-skill ~/books/book.pdf ~/notes/my-notes.md content-knowledge`

处理整个文件夹：

`1`	`/book-to-skill ~/documents/project-docs/ project-knowledge`

处理某个目录中的全部 EPUB 文件：

`1`	`/book-to-skill "~/books/*.epub" my-book-library`

Book to Skill 在正式生成前，还可以先分析文档结构、估算 Token 消耗，并展示预计生成的文件。

对于篇幅较长的书，建议先选择分析模式，确认提取出来的框架和章节是否准确，再继续生成完整 Skill。

一个实际应用案例

假设你有一本关于短视频内容创作的电子书。

转换成 Skill 后，可以让 AI 完成以下任务。

1. 快速了解全书

`1`	`请基于这个 Skill，整理全书的核心框架、关键原则和主要方法。`

2. 生成短视频方案

1
2

请使用书中的内容创作框架，策划一条介绍 Book to Skill 的 60 秒短视频。
需要包含标题、开头钩子、脚本结构、核心画面和结尾行动指令。

3. 检查现有脚本

请按照书中的评估标准，检查这份短视频脚本。

重点分析：
1. 标题点击潜力
2. 前 3 秒吸引力
3. 内容节奏
4. 信息密度
5. 留存风险
6. 惊喜点
7. 可以删除的内容
8. 具体修改方案

4. 查询书中概念

`1`	`请解释书中关于内容留存的核心方法，并说明它适合在哪些场景使用。`

5. 重写脚本

1
2
3

请根据书中的原则重写这份脚本。

保留原来的主题，但增强开头吸引力、内容节奏和结尾转化。

这时，AI 的判断依据不再只是通用知识，而是你提供的那本书中提取出来的框架。

Book to Skill 真正适合哪些人？

这个工具比较适合以下用户：

经常阅读技术书或商业书的人
想把读书笔记真正用于工作的人
内容创作者和短视频运营人员
产品经理与项目负责人
开发者和技术团队
需要频繁查询公司内部文档的团队
想建立个人 AI 知识库的人

如果你只是想快速知道一本书讲了什么，普通的 AI 总结已经足够。

如果你希望 AI 在未来的任务中持续使用书里的方法，Book to Skill 会更有价值。

使用时需要注意什么？

1. 不要把它当成万能知识转换器

生成效果取决于原始文档质量。

扫描模糊、排版混乱、缺少文字层或章节结构不清晰的 PDF，可能会影响内容提取结果。

2. 重要结论仍需回到原文核对

Skill 可以帮助查找、整理和应用知识，但不代表生成结果一定完全准确。

涉及专业决策、法律、医疗、财务或重要商业问题时，应重新核对原始章节。

3. 注意版权与使用权限

建议只处理以下资料：

自己购买并合法取得的电子书
自己创作的内容
公司授权使用的内部文档
开放许可资料
已进入公共领域的作品

不要随意转换、传播或公开分享无权处理的受版权保护内容。

4. 敏感文件应谨慎处理

项目官方说明，Book to Skill 主要在本地读取文档并写入 Skill 目录，不会主动上传文件或运行网络服务。

不过，最终生成和调用 Skill 时是否会把内容发送给云端模型，还取决于你使用的 AI 工具和模型服务。

处理公司机密、客户资料或个人隐私文件前，应先确认对应 AI 服务的数据政策。

5. 不要直接相信网络视频中的 Star 数量

GitHub Star 会随时间变化。

与其在文章中写死“6.9K Star”或其他数字，不如直接查看项目仓库中的实时数据，避免文章发布后很快过时。

我的理解

Book to Skill 最有价值的地方，不是帮助我们更快地“读完一本书”，而是改变书籍知识的使用方式。

过去，一本书读完之后，真正能记住和使用的内容可能很少。

现在可以把书里的框架、规则和方法整理成一个 Agent Skill，让 AI 在写作、分析、策划和决策时按需调用。

它相当于把一本静态的电子书，变成一个可以查询、分析并参与工作的知识模块。

不过，它并不能代替阅读本身。

真正合理的用法，是让 AI 帮助我们定位知识、理解框架和应用方法，再回到原文核对上下文。这样既能提高学习效率，也能减少断章取义和错误理解。

项目地址

GitHub：

https://github.com/virgiliojr94/book-to-skill

项目名称：

`1`	`virgiliojr94/book-to-skill`

项目功能、安装方式和兼容范围可能继续更新，请以 GitHub 仓库中的最新 README 为准。

Codex 效率倍增：5 个值得关注的开源工具

Mon, 27 Jul 2026 19:40:00 +0800

同样使用 Codex，为什么有些人写代码更快、更稳，还能让 AI 自动查文档、理解大型项目，甚至操作浏览器和电脑？

原因并不只是模型更强，而是他们给 Codex 配置了更完整的工具链。

Codex 本身已经可以阅读代码、修改文件、运行命令和修复 Bug，但在实际使用中，仍然容易遇到以下问题：

没有理解完整需求，就直接开始写代码；
使用过时的技术文档，生成已经失效的 API；
一个简单功能引入大量依赖，代码越来越复杂；
项目文件太多，AI 反复搜索代码，消耗大量 Token；
AI 能分析问题，却无法操作浏览器或桌面软件。

下面介绍 5 个值得关注的开源项目。它们分别从开发流程、网页数据、代码精简、项目理解和电脑自动化五个方向，补足 Codex 的能力。

本文中的 GitHub Star 数量会随时间变化，因此不再使用固定数字作为主要判断标准。是否值得安装，还应结合项目更新频率、Issue、许可证和实际需求综合判断。

5 个工具分别解决什么问题？

工具名称	核心功能	主要解决的问题
Superpowers	为 AI 加入需求分析、开发计划、测试和代码审查流程	AI 没想清楚就直接写代码
Firecrawl	抓取网页并转换为 Markdown 或结构化数据	AI 使用过时文档或无法读取网页
Ponytail	强调标准库优先、最小实现和减少依赖	代码过度设计、项目越来越臃肿
Graphify	将代码库转换为本地知识图谱	大型项目难理解、反复搜索文件
Agent TARS	识别屏幕并操作鼠标、键盘和浏览器	AI 只能思考，不能完成界面操作

1. Superpowers：让 Codex 先分析，再写代码

很多 AI 编程任务失败，并不是因为模型不会写代码，而是因为它在需求还没有明确时，就直接开始修改项目。

例如，你只说一句：

给网站增加一个用户登录功能。

AI 可能马上创建数据库、安装认证框架、增加多个中间件，最后才发现你只需要一个简单的后台密码验证。

Superpowers 的作用，就是给 Codex、Claude Code 等 AI 编程工具增加一套更严格的软件开发流程。

它通常会引导 AI 按照以下步骤工作：

先分析用户需求；
主动询问缺失的细节；
输出开发方案；
将任务拆分成多个步骤；
编写测试；
实现功能；
运行测试；
检查代码质量；
完成代码审查。

它更像是一套 AI 开发规范，而不是简单的提示词模板。

Superpowers 适合解决什么问题？

如果你经常遇到下面这些情况，可以考虑使用 Superpowers：

AI 没理解需求就开始修改代码；
功能做出来了，但方向完全错误；
修改一个问题，却破坏了其他功能；
AI 写完代码后不测试；
大型任务执行到一半开始偏离目标；
希望 Codex 按测试驱动开发流程工作。

使用时需要注意

Superpowers 会让开发流程更加完整，但也会增加执行步骤。

如果只是修改一个按钮颜色、调整一段文字或修复简单配置，并不一定需要启动完整的需求分析和测试流程。

它更适合中等以上复杂度的开发任务。

2. Firecrawl：让 Codex 获取最新网页和技术文档

AI 编程工具经常会遇到一个问题：模型掌握的知识不是实时更新的。

当框架、云服务或第三方 API 更新后，Codex 可能仍然使用旧版本参数，甚至生成已经被删除的方法。

例如：

Next.js 更新了路由方式；
OpenAI API 修改了请求格式；
Cloudflare 增加了新的配置参数；
某个 JavaScript 库废弃了旧方法；
官方文档已经更新，但 AI 仍然按照旧教程回答。

Firecrawl 是一个面向 AI Agent 的网页抓取和数据提取工具。

它可以将网页内容整理成适合 AI 阅读的格式，包括：

Markdown；
HTML；
JSON；
结构化数据；
网页截图；
页面链接；
整站爬取结果。

普通网页中通常包含导航栏、广告、按钮、脚本和大量无关代码。

Firecrawl 会尽量提取正文内容，再转换成干净的 Markdown，让 Codex 更容易理解。

Firecrawl 可以怎么配合 Codex？

例如，你准备让 Codex 接入一个刚刚更新的 API。

可以先让 Firecrawl 抓取官方文档，再把整理后的内容交给 Codex。

这样，Codex 不需要完全依赖模型记忆，而是根据最新文档生成代码。

一个常见工作流程是：

抓取官方文档
↓
转换为 Markdown
↓
交给 Codex 阅读
↓
根据最新文档生成代码
↓
运行测试验证

Firecrawl 适合哪些场景？

获取最新 API 文档；
抓取产品页面；
整理公开数据；
分析竞争对手网站；
提取新闻和文章正文；
给 AI Agent 提供实时互联网内容；
将复杂网页转换成 Markdown。

使用时需要注意

Firecrawl 的核心项目是开源的，但官方提供的云端 API 服务可能存在免费额度和付费套餐。

因此，“项目开源”不代表所有在线调用都永久免费。

如果需要大量抓取，也可以研究自托管方案。

同时，抓取网站时应遵守目标网站的 robots.txt、服务条款和相关法律要求。

3. Ponytail：阻止 AI 把简单问题写复杂

Codex 在生成代码时，有时会出现明显的过度设计。

一个原本只需要十几行代码的小功能，AI 可能会：

新建多个文件；
引入新的第三方库；
创建多层抽象；
增加复杂配置；
设计未来可能永远不会使用的扩展接口；
把简单逻辑封装成多个类。

最终结果是代码看起来很专业，但维护成本越来越高。

Ponytail 的核心思想是：

没有明确需要的功能，就不要提前实现。

这也是软件开发中常见的 YAGNI 原则，即：

You Aren’t Gonna Need It。

Ponytail 会引导 AI 优先考虑以下问题：

这个功能真的需要新增代码吗？
项目中是否已经存在类似能力？
能否直接使用语言标准库？
能否使用平台原生功能？
是否真的需要安装第三方依赖？
是否可以使用更简单的实现？
是否正在为不存在的未来需求过度设计？

举一个简单例子

假设需求是读取一个 JSON 文件。

AI 可能建议安装额外的 JSON 处理库。

但对于 Python、JavaScript、Go 等语言来说，标准库本身已经具备 JSON 解析能力。

Ponytail 会优先让 AI 使用现有能力，而不是为了一个简单任务增加新的依赖。

Ponytail 适合哪些用户？

个人开发者；
小型项目；
快速验证产品；
希望减少依赖的团队；
经常使用 Codex 生成代码的用户；
发现项目越改越复杂的开发者。

使用时需要注意

代码少并不代表代码一定更好。

涉及以下内容时，不能为了减少代码而省略必要设计：

安全验证；
错误处理；
日志记录；
数据校验；
权限控制；
自动化测试；
长期维护需要的模块拆分。

Ponytail 的重点不是“强行减少代码行数”，而是减少没有实际价值的复杂度。

4. Graphify：让 Codex 快速理解大型项目

当项目只有十几个文件时，Codex 通常可以快速理解代码结构。

但如果项目包含几百个甚至几千个文件，AI 就需要不断执行：

搜索文件；
查找函数；
阅读调用关系；
打开配置文件；
查找数据库结构；
分析模块依赖；
重复读取相同代码。

这个过程不仅慢，还会消耗大量上下文和 Token。

Graphify 可以提前分析整个项目，并将项目内容转换为本地知识图谱。

它可以处理的内容包括：

源代码；
项目文档；
配置文件；
数据库 Schema；
Markdown；
PDF；
图片；
视频；
其他项目资料。

对于代码内容，Graphify 可以使用 Tree-sitter 进行结构化解析，从而识别：

文件之间的关系；
函数调用关系；
类和模块依赖；
代码入口；
数据流；
配置关联；
项目目录结构。

Graphify 能帮助 Codex 回答什么问题？

建立知识图谱后，可以让 AI 更快回答：

用户登录功能涉及哪些文件？
这个函数被哪些模块调用？
修改数据库字段会影响哪些页面？
项目入口文件在哪里？
支付流程经过哪些服务？
某个配置项会影响哪些组件？
这段代码是否存在循环依赖？
一个 Bug 可能来自哪些模块？

相比让 Codex 每次从头搜索整个项目，知识图谱能够提供更完整的项目上下文。

Graphify 适合哪些场景？

接手陌生项目；
分析大型代码仓库；
维护遗留系统；
阅读缺少文档的项目；
多个 AI Agent 协作开发；
进行代码影响范围分析；
降低重复读取项目文件的次数。

使用时需要注意

知识图谱只能帮助 AI 理解代码关系，不能替代真实测试。

即使 Graphify 判断某个函数只被三个模块调用，也仍然需要通过运行测试和实际环境验证修改结果。

另外，项目代码发生较大变化后，需要重新更新或增量更新知识图谱。

5. Agent TARS：让 AI 从思考走向操作

Codex 更擅长处理代码、命令行和文件。

但很多实际工作并不完全发生在终端中，例如：

打开网页后台；
点击菜单；
填写表单；
上传文件；
操作设计软件；
整理网页内容；
使用桌面应用；
在浏览器中完成多步骤任务。

Agent TARS 是字节跳动开源的多模态 AI Agent 项目。

它可以结合视觉模型、GUI Agent 和 MCP 工具，让 AI 尝试理解屏幕内容，并进行鼠标、键盘和浏览器操作。

它的能力方向包括：

识别页面按钮；
理解输入框和菜单；
点击网页元素；
输入文字；
操作浏览器；
调用 MCP 工具；
完成多步骤界面任务；
结合搜索、文件和网页工具工作。

Agent TARS 能做什么？

理论上，你可以给它一个任务，例如：

打开网站后台，找到最近发布的文章，并检查标题是否存在错别字。

AI 会尝试：

打开浏览器；
进入对应页面；
识别后台菜单；
找到文章列表；
打开文章；
分析页面内容；
返回检查结果。

这类工具让 AI 不再只是告诉你“应该点击哪里”，而是尝试直接执行界面操作。

Agent TARS 适合哪些场景？

浏览器自动化；
GUI Agent 研究；
网页后台操作；
重复性桌面任务；
多步骤资料整理；
Computer Use 测试；
MCP 工具调用。

使用时需要注意

不要把 Agent TARS 理解成可以完全放心接管电脑的工具。

GUI Agent 仍然可能出现：

点击错误位置；
误解页面内容；
输入错误信息；
删除不该删除的文件；
在错误账号中执行操作；
页面加载后判断失败；
执行高风险操作。

建议优先在以下环境中测试：

虚拟机；
测试账号；
低权限用户；
不包含重要文件的电脑；
隔离的浏览器环境。

涉及以下操作时，应保留人工确认：

发布内容；
删除文件；
修改账号；
发送邮件；
提交订单；
付款；
上传隐私文件；
修改服务器配置。

这 5 个工具应该怎么选择？

不需要一次性把所有工具全部安装。

更合理的方式是先找到自己当前最明显的问题，再选择对应工具。

AI 写代码经常跑偏

选择：

`1`	`Superpowers`

它适合帮助 Codex 先明确需求，再按照计划、测试和代码审查流程执行。

经常遇到过时 API 和技术文档

选择：

`1`	`Firecrawl`

它可以抓取最新官方文档，并转换成适合 AI 阅读的 Markdown。

AI 生成的代码越来越复杂

选择：

`1`	`Ponytail`

它会提醒 AI 优先使用现有代码、标准库和原生能力，减少不必要的依赖。

项目太大，Codex 总是找不到代码关系

选择：

`1`	`Graphify`

它可以将项目转换为知识图谱，让 AI 更快理解项目结构和调用关系。

希望 AI 操作浏览器和桌面软件

选择：

`1`	`Agent TARS`

它适合研究 GUI Agent、浏览器自动化和 Computer Use。

是否都支持 Codex、Cursor 和 Claude Code？

不能简单地理解成“安装一次，所有 AI 编程工具全部通用”。

不同项目的接入方式可能包括：

Agent Skills；
MCP Server；
CLI 命令；
API；
本地服务；
Docker；
插件配置；
自定义提示词；
项目规则文件。

例如，某个项目可能更适合 Claude Code，另一个项目可能主要通过 MCP 接入 Cursor，也可能需要手动配置 Codex。

因此，具体安装和兼容方式应以项目最新 README 为准。

使用开源 AI 工具前，建议检查这些内容

不要只看 GitHub Star 数量。

安装前建议重点检查：

1. 最近是否仍在更新

查看最近一次提交时间和版本发布时间。

如果项目长期没有维护，可能无法兼容最新 Codex、Cursor 或 MCP 协议。

2. Issue 中是否存在严重问题

重点关注：

安装失败；
数据泄露；
高 CPU 占用；
无法卸载；
Windows 兼容问题；
macOS 权限问题；
API Key 泄露；
项目无法启动。

3. 是否需要额外付费服务

有些项目本身开源，但可能依赖：

OpenAI API；
Claude API；
Gemini API；
Firecrawl 云服务；
向量数据库；
云服务器；
搜索 API。

因此，开源不一定等于零成本。

4. 是否会读取敏感代码

如果项目需要扫描整个代码仓库，要先确认数据是否只在本地处理。

涉及公司代码、客户项目或商业机密时，不要直接上传到不确定的第三方服务。

5. 是否拥有高权限

GUI Agent 和电脑自动化工具可能需要：

屏幕录制权限；
鼠标控制权限；
键盘控制权限；
浏览器访问权限；
文件系统权限。

安装前应明确它可以访问哪些数据。

总结

提升 Codex 的效率，并不只是更换一个更强的模型。

真正影响 AI 编程体验的，通常还有三件事：

是否有明确的开发流程；
是否能获得最新、准确的资料；
是否能快速理解当前项目。

Superpowers 负责规范开发流程，Firecrawl 负责获取实时网页和技术文档，Ponytail 负责控制代码复杂度，Graphify 负责理解大型项目，Agent TARS 则将 AI 能力扩展到浏览器和桌面操作。

但工具并不是越多越好。

更实际的做法是：

找到工作流中最浪费时间、最容易出错的一步，再安装对应工具。

如果 Codex 经常写错方向，就先解决需求分析问题。

如果 AI 经常引用过时 API，就先解决实时文档问题。

如果项目越来越复杂，就先限制过度设计。

如果大型项目理解困难，就建立本地知识图谱。

只有真正需要操作网页和电脑时，再考虑 GUI Agent。

GitHub 项目地址

Superpowers https://github.com/obra/superpowers
Firecrawl https://github.com/firecrawl/firecrawl
Firecrawl MCP Server https://github.com/firecrawl/firecrawl-mcp-server
Ponytail https://github.com/DietrichGebert/ponytail
Graphify https://github.com/Graphify-Labs/graphify
Agent TARS / UI-TARS Desktop https://github.com/bytedance/UI-TARS-desktop

Find Skills 使用教程：帮你搜索、筛选和安装合适的 AI Agent Skills

Mon, 27 Jul 2026 19:10:00 +0800

Skills 太多不知道装哪个？先用 Find Skills 帮你筛选

接触 Claude Code、Codex、Cursor 或其他 AI Agent 一段时间后，很多人都会遇到同一个问题：

可安装的 Skills 越来越多，但真正适合自己的却很难找。

看到别人推荐测试 Skills、SEO Skills、前端设计 Skills、亚马逊选品 Skills，很多新手的第一反应是全部收藏，或者看到一个就安装一个。

最后工具箱越来越大，真正使用的可能只有两三个。

与其花时间在 GitHub 和 Skills.sh 里逐个翻找，不如先安装一个专门帮助你寻找 Skills 的 Skills：Find Skills。

Find Skills 是什么？

Find Skills 的代码名称是 find-Skills，由 Vercel Labs 的 Skills 项目提供。

它不是用来替你写代码、做选品或制作视频的业务型 Skills，而更像一个 AI Skills 导航员。

它主要做三件事：

根据你的实际任务寻找相关 Skills；
对搜索结果进行初步筛选；
提供 Skills 的用途、来源和安装命令。

你只需要把需求说清楚，它就会帮助你缩小范围，而不是让你面对一长串不知道该怎么选择的 Skills。

为什么建议先安装 Find Skills？

真正的问题通常不是没有 Skills，而是 Skills 太多。

Skills.sh 是一个开放的 Agent Skills 目录，里面收录了大量可复用能力。Skills 可以理解为一组面向特定任务的操作说明、脚本和相关资源，用来教 AI Agent 按照相对固定的流程完成工作。

但 Skills 数量增加后，也会带来三个问题：

名称相似，不知道哪个更适合；
来源不同，质量差距较大；
安装太多后，管理和维护成本上升。

因此，Find Skills 的价值不只是“帮你搜索”，而是先理解任务，再帮助你判断哪些结果更值得进一步查看。

Find Skills 是怎么寻找 Skills 的？

根据其官方说明，Find Skills 通常会按照以下流程工作。

第一步：拆解你的真实需求

它会先判断：

你属于哪个领域；
你具体想完成什么任务；
这个任务是否可能已经有成熟的 Skills。

例如，“我想做亚马逊”范围太大。

更有效的表达是：

帮我寻找一个适合亚马逊产品研究的 Skills，重点关注关键词、竞品分析、市场需求和广告数据。

需求越具体，搜索结果通常越准确。

第二步：先查看热门 Skills

Find Skills 会先检查 Skills.sh 排行榜，看看相关领域是否已经存在安装量较高、使用较广的 Skills。

热门不代表一定适合你，但通常意味着有更多用户使用和验证，可以作为第一轮筛选依据。

第三步：使用关键词继续搜索

如果排行榜中没有合适的结果，它会使用 Skills CLI 继续搜索，例如：

`1`	`npx Skills find amazon product research`

Skills CLI 也支持直接按关键词搜索：

`1`	`npx Skills find typescript`

还可以限定 GitHub 用户或组织：

`1`	`npx Skills find react --owner vercel`

第四步：核对 Skills 的质量

Find Skills 不应该只根据搜索结果名称进行推荐，还会重点查看：

安装量；
作者或组织来源；
GitHub 仓库星标；
项目是否持续维护；
Skills 的实际用途；
是否与当前任务匹配。

官方指南建议优先考虑安装量较高、来源可信的 Skills；安装量很少、来源陌生或仓库维护不足的项目，则需要更加谨慎。

Find Skills 安装命令

可以使用下面的命令安装 Vercel Labs 提供的 find-Skills：

`1`	`npx Skills add vercel-labs/Skills --Skills find-Skills`

在支持指定 Agent 的环境中，也可以明确选择安装目标。例如安装到 Claude Code：

`1`	`npx -y Skills add vercel-labs/Skills --Skills find-Skills --agent claude-code`

执行方法很简单：

打开终端；
粘贴安装命令；
按下回车；
根据终端提示完成安装。

需要注意的是，不同 Agent 和 Skills CLI 版本的安装路径或参数可能有所区别。安装前可以先查看项目最新说明。

安装后怎么使用？

安装完成后，不需要记住复杂命令，可以直接使用自然语言描述需求。

例如：

帮我寻找一个用于前端自动化测试的 Skills，优先推荐来源可信、安装量较高并且仍在维护的项目。

或者：

帮我找一个适合独立站 SEO 内容分析的 Skills，需要支持关键词研究、竞品分析和内容缺口检查。

还可以进一步增加筛选条件：

请先说明每个 Skills 的用途、作者来源、安装量、GitHub 仓库情况和安装命令，不要直接安装，等我确认后再操作。

这样做可以避免 AI 搜到结果后立即安装，也方便你先比较不同选项。

哪些人适合使用 Find Skills？

Find Skills 并不只适合程序员。

程序员

可以寻找：

自动化测试 Skills
代码审查 Skills
Git 提交规范 Skills
React 或 Next.js 优化 Skills
部署和排错 Skills

跨境电商卖家

可以寻找：

亚马逊选品 Skills
关键词研究 Skills
竞品分析 Skills
Listing 优化 Skills
广告数据分析 Skills

内容创作者

可以寻找：

视频脚本 Skills
标题生成 Skills
SEO 内容优化 Skills
社交媒体分发 Skills
字幕和内容整理 Skills

个人网站站长

可以寻找：

技术 SEO 检查 Skills
网站性能优化 Skills
结构化数据 Skills
内容审查 Skills
Google Search Console 分析 Skills

核心原则只有一个：

不要按照 Skills 的名字搜索，而要按照自己准备完成的任务搜索。

安装第三方 Skills 前要注意什么？

Find Skills 可以帮你缩小范围，但不能代替最终的安全判断。

安装之前，建议至少检查以下内容：

查看作者来源

优先考虑官方组织、知名开发者或长期维护的开源仓库。

阅读 Skills.md

确认它会执行哪些步骤、调用哪些命令，以及是否会修改本地文件。

检查脚本和依赖

如果 Skills 带有 Shell、Python、JavaScript 脚本，应先查看脚本内容，不要直接运行来源不明的代码。

检查更新时间和 Issue

长时间没有更新、存在大量未处理问题的项目，需要谨慎安装。

不要一次安装几十个

先根据当前任务安装两三个真正需要的 Skills，使用一段时间后再决定是否保留。

Find Skills 和 `npx Skills find` 有什么区别？

两者都可以帮助你搜索 Skills，但使用方式不同。

npx Skills find 是直接在终端中搜索：

`1`	`npx Skills find seo`

Find Skills 则会先理解你的自然语言需求，再决定搜索哪些关键词，并帮助你整理和比较结果。

简单理解：

npx Skills find 是搜索工具；
Find Skills 是帮助你使用搜索工具的导航规则。

对于已经知道准确关键词的人，直接使用命令会更快。

对于不知道该搜什么、也不知道如何判断质量的新手，Find Skills 更容易上手。

我的使用建议

不要一开始就安装几十个 Skills。

更合理的顺序是：

先安装 Find Skills；
明确当前准备完成的任务；
让它推荐两到三个候选 Skills；
检查来源、安装量、仓库和脚本；
只安装真正适合当前工作的项目；
定期删除长期不用的 Skills。

Find Skills 节省的不只是搜索时间。

更重要的是，它可以减少无效安装，让你的 AI Agent 工具箱保持轻量，并把注意力重新放回真正需要完成的任务上。

项目地址

Find Skills GitHub 项目：https://github.com/vercel-labs/Skills/tree/main/Skills/find-Skills
Skills.sh：https://Skills.sh
Skills CLI 项目：https://github.com/vercel-labs/Skills

AnySearch Skill：为 AI Agent 减少无效搜索与 Token 浪费

Mon, 27 Jul 2026 16:47:00 +0800

在使用 Codex、Claude Code、OpenClaw 等 AI Agent 时，联网搜索看起来只是一个简单功能，但实际执行起来非常消耗上下文。

传统搜索通常会返回大量网页摘要、HTML 内容、导航菜单和广告信息。Agent 需要先读取这些杂乱内容，再从中筛选真正有用的部分。搜索次数一多，不仅会快速占用上下文窗口，也会增加 Token 消耗和任务成本。

AnySearch Skill 就是为解决这个问题而设计的搜索工具。它为 AI Agent 提供统一的实时搜索能力，支持普通网页搜索、垂直领域搜索、批量并行查询和网页正文提取。

它解决了什么问题？

AI Agent 在执行编程、调研或资料整理任务时，经常需要经历下面几个步骤：

搜索相关网页；
打开多个搜索结果；
清理页面中的无关内容；
提取真正有价值的信息；
对多个来源进行整理和对比。

如果这些工作全部交给模型完成，大量无效内容也会被送入上下文。

AnySearch 的思路，是把搜索、内容提取和结果结构化等工作交给专门的搜索服务处理，然后再把相对精简的结果返回给 Agent。

这样做并不意味着完全不消耗 Token，而是能够减少无关网页内容进入上下文，让 Agent 把更多精力放在分析、判断和执行任务上。

AnySearch Skill 的主要能力

1. 普通网页搜索

Agent 可以通过统一命令查询网页、新闻、技术资料和公开信息，不需要为每一种搜索服务单独编写调用流程。

这类搜索适合：

查询软件使用方法；
查找项目文档；
搜索行业资讯；
寻找产品或服务信息；
获取近期公开资料。

2. 垂直领域搜索

相比只使用普通关键词搜索，AnySearch 还支持面向特定领域的搜索路由。

例如在处理代码、金融、学术、法律、旅行或商业问题时，Agent 可以选择更合适的数据领域，而不是把所有问题都扔进普通网页搜索。

这种方式更容易获得结构化、相关性更高的结果，也能减少 Agent 在大量网页之间反复筛选。

3. 批量并行搜索

当一个任务中包含多个独立问题时，Agent 可以使用批量搜索，一次提交多组查询。

例如制作一份出差计划时，可能需要同时查询：

当地天气；
交通路线；
酒店位置；
餐厅信息；
展会或会议安排。

如果逐项搜索，会产生多轮调用。批量搜索可以并行获取结果，再由 Agent 统一整理，更适合复杂调研任务。

4. 网页正文提取

普通搜索结果通常只有标题和简短摘要，并不足以支撑深入判断。

AnySearch Skill 提供网页内容提取能力，可以将网页正文整理为 Markdown，方便 Agent 继续进行摘要、对比、引用和内容创作。官方仓库目前提供 Python、Node.js、PowerShell 和 Bash 等多种命令行入口。

为什么它能减少 Token 消耗？

传统的 Agent 搜索流程大致是：

搜索网页
→ 获取大量原始页面内容
→ Agent 阅读全部内容
→ 清理广告和无关信息
→ 提取重点
→ 分析结果

AnySearch 的流程更接近：

Agent 提交问题
→ 搜索服务完成检索和内容处理
→ 返回相对结构化的结果
→ Agent 直接分析重点信息

两者最大的区别，是谁来处理搜索产生的冗余内容。

传统方式主要依赖 Agent 自己清理；AnySearch 则尽可能在搜索和提取环节提前处理，再将结果交给 Agent。

因此，它更适合需要频繁联网、批量调研或者读取大量网页资料的工作流。

哪些场景比较适合？

编程与项目开发

可以帮助 Codex 或其他编码 Agent 查询：

GitHub 项目；
软件库文档；
API 使用方法；
报错解决方案；
版本更新信息；
技术文章和代码示例。

内容与行业研究

适合搜索多个来源，整理：

行业动态；
市场趋势；
竞品资料；
公司背景；
产品信息；
学术论文和专业资料。

自动化 Agent 工作流

对于需要持续执行搜索、整理和分析任务的 Agent，AnySearch 可以作为一个统一的搜索入口。

它不仅告诉 Agent“可以搜索”，还通过 SKILL.md 定义搜索方式、调用流程和工具使用规则，让搜索能力更容易被不同 Agent 环境复用。

使用前需要注意什么？

AnySearch Skill 并不是完全运行在本地的搜索引擎。

开源仓库主要包含 Skill 说明、配置文件和跨平台命令行脚本，实际搜索和网页处理会调用 AnySearch 的在线服务。因此，查询关键词和需要提取的网页地址可能会发送到第三方服务。

使用时需要注意：

不要搜索密码、密钥或个人隐私；
不要提交未公开的商业机密；
不要把搜索摘要直接当作最终事实；
金融、医疗和法律信息仍需核对权威来源；
重要结论最好进行多来源交叉验证。

此外，它更适合搜索和正文提取，并不能完全替代浏览器自动化工具。遇到需要登录、点击按钮、填写表单或操作复杂网页的任务，仍然需要配合浏览器工具使用。

是否需要 API Key？

AnySearch 支持匿名访问，但官方说明中提到，匿名模式的调用频率和额度会更低。配置 API Key 后，更适合频繁搜索或长期 Agent 工作流。

API Key 应保存在 .env 或系统环境变量中，不建议直接粘贴到聊天窗口、提示词或公开代码仓库。

总结

AnySearch Skill 的价值，并不是简单地给 AI 增加一个搜索框，而是帮助 Agent 建立一套更完整的搜索流程：

判断是否需要联网
→ 选择普通或垂直搜索
→ 必要时批量查询
→ 提取关键网页正文
→ 核对来源
→ 输出最终结果

对于经常使用 Codex、Claude Code 或其他 AI Agent 进行编程、资料整理和深度调研的用户来说，它可以减少搜索产生的无效上下文，让 Agent 更专注于分析和执行任务。

不过，它并不能保证每一次搜索都更省 Token，也不能替代事实核验。更准确地说，它是一层面向 AI Agent 的搜索基础设施：通过结构化搜索、批量查询和网页正文提取，降低 Agent 处理杂乱网页信息的负担。

项目地址

GitHub:https://github.com/anysearch-ai/anysearch-skill

降低 Token 消耗的文章

jCodeMunch MCP 使用教程：让 Codex、Claude Code 少读废代码，降低 Token 消耗

Codex 省额度工具包（新手版）

PPT Master：免费开源的 AI PPT 工具，生成真正可编辑的 PowerPoint

Mon, 27 Jul 2026 09:27:00 +0800

现在的 AI PPT 工具很多，但不少工具生成的只是图片、网页截图，或者套用固定模板拼出来的页面。

看起来像 PPT，真正需要修改时却很麻烦：文字不能单独调整、图表无法重新编辑、排版稍微改动就容易错位。

最近我发现了一个很实用的开源项目——PPT Master。

它最大的特点，是能够根据文档、资料或主题，生成真正的 .pptx 文件。PPT 里的文字、图形、配色和部分图表都可以继续在 PowerPoint、WPS、Keynote 等软件中修改，而不是把整页内容做成一张无法编辑的图片。

截至本文整理时，这个项目在 GitHub 上已经获得约 3.3 万颗 Star，并且仍在持续更新。

PPT Master 是什么？

PPT Master 是一套运行在 AI 编程工具中的 PPT 生成工作流。

安装完成后，可以在 Claude Code、Codex、Cursor、VS Code Copilot 等支持读取文件和执行命令的 AI 工具中，直接用自然语言告诉它：

根据这份产品资料，生成一套 12 页的中文产品介绍 PPT。

AI 会自动分析内容、规划页面结构、设计视觉风格，并导出可以继续编辑的 PowerPoint 文件。

它不是传统意义上的在线 PPT 网站，也不是打开网页后输入一句话就能生成的 SaaS 服务，而是一套需要部署在本地、配合 AI Agent 使用的开源工具。

它有什么特别之处？

1. 生成真正可编辑的 PPTX

这是 PPT Master 最有价值的地方。

项目通过 SVG 和 PowerPoint 原生 DrawingML 结构生成 PPT，最终导出的文字、形状、颜色和图形，可以作为 PowerPoint 对象继续调整。

生成完成后，你仍然可以：

修改标题和正文；
更换字体与颜色；
移动图标和形状；
调整版式和间距；
修改图表文字；
添加公司 Logo；
替换图片和品牌元素。

拿到的不是一套“看起来像 PPT 的图片”，而是一份真正可以修改和交付的演示文稿。

2. 支持多种内容来源

PPT Master 可以根据主题直接制作内容，也可以读取已有资料重新整理，例如：

Markdown 文档；
Word 文档；
PDF 文件；
HTML 网页；
EPUB 文件；
Jupyter Notebook；
已有的 PPTX 文件；
本地图片和项目资料。

你可以把产品介绍、项目方案、行业报告或会议资料放进项目目录，让 AI 根据原始材料生成 PPT。

3. 支持多种内容结构与视觉风格

PPT Master 将内容逻辑和视觉风格分开处理。

内容结构可以选择：

金字塔汇报；
故事叙述；
教程说明；
产品展示；
工作简报。

视觉上则可以选择瑞士极简、编辑杂志、柔和圆角、暗黑科技等不同方向，也可以根据企业品牌要求自定义风格。

因此，它不仅适合普通工作汇报，也可以用于：

产品介绍；
项目方案；
商业计划书；
行业分析；
教学课件；
公司培训；
商业路演；
咨询报告；
年度总结。

4. 支持动画、旁白和视频导出

项目支持页面转场和元素动画，还可以根据演讲者备注生成语音旁白，并将音频嵌入 PPT。

之后可以通过 PowerPoint 将整套演示文稿导出为带旁白和转场的视频。

5. 不只可以制作 PPT

除了常见的 16:9 和 4:3 演示文稿，PPT Master 还支持生成多种内容尺寸：

小红书 3:4 图文；
微信朋友圈 1:1 图片；
Instagram 方形内容；
短视频竖屏封面；
微信公众号头图；
A4 海报和宣传页。

这些内容最终仍可以导出为带有可编辑元素的 PPTX 文件。

PPT Master 使用方法

下面以 Windows 系统为例介绍。

第一步：安装 Python

PPT Master 需要 Python 3.10 或更高版本。

安装 Python 时，一定要勾选：

`1`	`Add python.exe to PATH`

安装完成后，打开 PowerShell，输入：

`1`	`python --version`

能够看到 Python 版本号，就说明安装成功。

第二步：下载项目

熟悉 Git 的用户，可以在 PowerShell 中执行：

1
2

git clone https://github.com/hugohe3/ppt-master.git
cd ppt-master

不熟悉 Git，也可以直接打开 GitHub 项目页面，点击：

`1`	`Code → Download ZIP`

下载完成后解压到本地文件夹。

第三步：安装依赖

进入项目目录后执行：

`1`	`pip install -r requirements.txt`

如果系统提示找不到 pip，可以改用：

`1`	`python -m pip install -r requirements.txt`

安装完成后，可以执行下面的命令检查环境：

`1`	`python -c "import pptx; import fitz; print('All core dependencies OK')"`

如果显示：

`1`	`All core dependencies OK`

说明核心环境已经配置完成。

第四步：使用 AI 工具打开项目

接下来使用支持 Agent 功能的 AI 工具打开 ppt-master 文件夹，例如：

Codex；
Claude Code；
Cursor；
VS Code Copilot；
其他能够读取文件并执行终端命令的 AI Agent。

打开后，可以先输入一条简单的测试指令：

请创建一份 3 页的测试 PPT。

主题：人工智能如何提高工作效率。

页面结构：
1. 封面
2. 主要应用场景
3. 总结

使用简洁、现代的商务风格，生成中文内容，并导出为可编辑的 PPTX 文件。

执行完成后，生成的 PPT 文件通常会保存在：

exports

目录中。

如何修改生成结果？

PPT 生成后，不需要整套重新制作。

假如某一页出现问题，可以直接告诉 AI：

`1`	`第 3 页标题和图表发生重叠，请重新调整这一页的版式，其他页面不要修改。`

也可以继续提出更具体的要求：

`1`	`将第 5 页改为左右分栏布局。`

`1`	`第 7 页文字太多，请压缩内容并增加一张信息图。`

`1`	`将整套 PPT 修改为深色科技风，但不要改变原来的内容结构。`

PPT Master 支持针对单独页面进行重新生成和修复，不一定每次都要从头开始。

使用时需要注意什么？

PPT Master 本身免费，但 AI 模型不一定免费

PPT Master 使用 MIT 开源协议，项目本身可以免费使用。

但是，它需要配合 Claude Code、Codex、Cursor 或其他 AI 模型工作，因此可能产生模型订阅费或 API 调用费用。

它不是完全零门槛的一键工具

第一次使用时，需要完成：

安装 Python；
下载项目；
安装依赖；
配置 AI 编程工具；
必要时配置模型或图片 API。

对于完全没有接触过本地部署的用户来说，前期需要一点学习成本。

最终效果仍然取决于资料和提示词

AI 能够提高制作效率，但无法代替内容判断。

如果提供的资料过于简单，或者没有明确告诉 AI 使用场景、受众和页面重点，生成结果也容易显得空泛。

建议提前准备：

完整的原始资料；
明确的汇报对象；
大概的页面数量；
企业配色和 Logo；
参考 PPT 或视觉案例；
希望重点表达的数据。

总结

PPT Master 最值得关注的地方，并不是“AI 可以自动做 PPT”，而是它解决了 AI PPT 工具普遍存在的一个问题：

生成之后还能不能继续编辑。

它输出的是原生可编辑的 PowerPoint 文件，而不是简单的图片或网页截图。对于经常需要制作工作汇报、产品介绍、项目方案、行业报告和商业路演的人来说，这种可编辑性非常重要。

虽然前期需要安装环境，并配合 Codex、Claude Code、Cursor 等 AI 工具使用，但完成配置后，就可以把它变成一套长期使用的本地 AI PPT 工作流。

如果你平时经常制作 PPT，这个项目值得收藏和尝试。

项目地址

GitHub：

`1`	`https://github.com/hugohe3/ppt-master`

项目主页：

`1`	`https://hugohe3.github.io/ppt-master/`

中文说明：

`1`	`https://github.com/hugohe3/ppt-master/blob/main/README_CN.md`

Windows 安装指南：

`1`	`https://github.com/hugohe3/ppt-master/blob/main/docs/windows-installation.md`

让 Codex 越用越聪明：用一套长期规则积累项目经验

Sat, 25 Jul 2026 22:38:00 +0800

很多人在使用 Codex 时，会遇到一个明显的问题：

同样的错误反复出现，同样的项目规范需要重复说明，每次开始新任务，都像重新认识一个陌生的助手。

想解决这个问题，单靠一句“记住我的习惯”并不够。更有效的方法，是通过一段初始化提示词，为 Codex 建立一套长期工作规则，让它主动记录经验、复盘问题，并在新项目开始前读取这些规则。

这套方法的核心，是让 Codex 自动创建并持续维护三个文档：

全局工作台
全局复盘日志
新项目 SOP

它们共同组成一套可持续积累的项目知识库。

一、为什么要建立长期工作规则？

Codex 很擅长执行当前任务，但它并不会天然理解你的全部开发习惯。

例如，你可能希望它：

修改代码前先理解项目结构；
尽量只改动必要文件；
不要随意重构无关代码；
每次修改后说明改了什么；
遇到错误时记录原因和解决办法；
创建新项目时使用统一目录和命名方式。

如果每次都重新输入这些要求，不仅麻烦，也容易遗漏。

因此，更合理的做法不是不断追加临时提示词，而是建立一套固定文档，让 Codex 在工作前主动读取，在工作后持续更新。

二、三个核心文档分别做什么？

1. 全局工作台

全局工作台相当于 Codex 的“工作说明书”。

它主要用于规定 Codex 的通用行为，例如：

开始任务前需要检查哪些内容；
修改代码时应遵守什么原则；
哪些文件可以修改，哪些文件不要轻易触碰；
项目文档分别放在哪里；
不同规则文件之间如何配合；
完成任务后需要输出哪些说明。

全局工作台还可以作为整个规则体系的目录，帮助 Codex快速找到其他文档。

简单来说，它解决的是：

Codex 应该按照什么方式工作。

2. 全局复盘日志

全局复盘日志用于记录实际工作中出现过的问题。

可以写入的内容包括：

曾经修改错误的文件；
因不了解项目结构导致的问题；
重复出现的命令错误；
构建、测试或部署失败的原因；
用户已经明确否定过的方案；
已经验证有效的解决方法；
今后遇到类似问题时应如何处理。

复盘日志不是普通的操作记录，而是一份可复用的经验库。

每完成一个重要任务，Codex 都可以检查：

这次是否出现了错误；
错误为什么发生；
下次如何避免；
有没有可以复用的方法。

这样做的意义在于，同一个坑尽量只踩一次。

3. 新项目 SOP

新项目 SOP 用来规定创建新项目时的标准流程。

例如可以要求：

每个项目必须使用独立文件夹；
项目名称采用统一格式；
创建 README、任务记录和状态文档；
开发前先确认技术栈和目录结构；
不在桌面或临时目录随意堆放文件；
初始化 Git 仓库并配置忽略文件；
重要操作前先备份；
完成初始搭建后记录项目状态。

它解决的是：

新项目应该按照什么顺序开始。

有了这份 SOP，即使同时管理多个项目，也能尽量保持目录、文档和操作方式一致。

三、把规则写入 Agent.md

三个文档创建完成后，还需要在项目的核心规则文件中加入一条最高优先级指令。

常见文件名可能是：

1
2
3

AGENTS.md
Agent.md
agents.md

具体名称需要根据 Codex 当前使用的规则机制和项目结构决定。

可以在其中写入类似规则：

执行任何新项目或重要任务之前，必须先阅读全局工作台、全局复盘日志和新项目 SOP。确认理解相关规则后，再开始分析、修改或创建文件。

这一步非常重要。

如果只是创建文档，却没有要求 Codex 在任务开始前主动读取，那么这些文档很容易变成无人使用的资料。

真正有效的机制应该是：

开始任务
  ↓
读取全局规则
  ↓
查看历史复盘
  ↓
按照 SOP 执行
  ↓
完成任务
  ↓
记录新的经验

这样才能形成完整闭环。

四、它为什么会“越用越聪明”？

这里所说的“越用越聪明”，并不是让 Codex 自动升级模型，也不是增加账户额度。

它真正改变的是工作上下文。

随着任务不断增加，复盘日志里会逐渐积累：

你常用的技术栈；
你不喜欢的代码风格；
你习惯的目录结构；
项目中容易出错的位置；
已经尝试过但失败的方案；
更适合你的操作流程；
不同项目之间可以复用的经验。

当 Codex 每次工作前都读取这些信息，它就能减少重复试错，也更容易按照你的习惯完成任务。

从实际体验上看，它会表现得越来越稳定，也越来越像一个熟悉你项目的长期协作者。

五、这套机制需要注意什么？

虽然长期规则很有用，但并不是文档越多越好。

首先，规则要保持简洁。过多重复、冲突或已经失效的内容，反而会干扰 Codex 的判断。

其次，复盘日志要记录结论，而不是堆积完整聊天内容。建议重点保留：

问题是什么；
原因是什么；
最终如何解决；
下次应该怎么做。

最后，重要规则仍然应该保存在项目文件中，而不是完全依赖模型自身的临时上下文。文件更容易检查、修改、同步和备份，也适合在多台电脑或团队成员之间共享。

总结

想让 Codex 更懂你的项目，关键并不是不断寻找更长、更复杂的提示词，而是建立一套可以持续维护的工作机制。

通过全局工作台统一行为规则，通过全局复盘日志沉淀经验，再通过新项目 SOP 规范项目初始化流程，最后将“任务开始前必须阅读这些文档”写入 AGENTS.md，就能形成一个不断积累和复用经验的闭环。

它不会让 Codex 的模型能力发生变化，但能明显减少重复沟通、无关修改和重复踩坑。

真正让 Codex 越用越顺手的，不是一段神奇提示词，而是一套能够长期执行、持续复盘、不断更新的项目规则体系。

国内信用卡订阅 ChatGPT、Gemini、Grok：安卓端完整操作指南

Fri, 24 Jul 2026 22:30:00 +0800

在订阅 ChatGPT Plus、Google Gemini、Grok 等海外 AI 服务时，很多国内用户都会遇到同一个问题：

明明手里有 Visa 或 Mastercard 信用卡，但在官网付款时仍然被拒绝；使用虚拟卡又要承担开卡费、充值费、汇率差价和平台稳定性等问题。

经过实际尝试后，我更倾向于优先使用官方应用商店提供的应用内订阅渠道。

对于安卓用户来说，可以尝试通过 Google Play 完成付款。整个过程不需要将银行卡交给第三方代充平台，订阅和续费也可以直接在 Google Play 中管理。

不过需要提前说明：

能否成功绑定，取决于银行卡、发卡银行、Google 账号地区和商户风控。
Google Play 显示的价格可能包含税费或汇率换算。
不同地区的订阅价格可能不同。
账单信息应与银行卡和实际使用情况保持一致。
本文不能保证所有国内信用卡都能成功付款。

下面我以安卓手机为例，整理一套相对完整的操作流程。

一、先了解基本原理

部分海外 AI 服务的官网支付会使用 Stripe 等国际支付渠道。

即使银行卡本身支持 Visa 或 Mastercard，付款仍有可能因为以下原因被拒绝：

发卡地区不受商户支持
银行关闭了境外线上支付
商户不接受当前卡段
账单地址不一致
IP 地址、账号地区和银行卡地区冲突
触发平台的支付风控
不支持 3D Secure 验证
银行拦截了自动续费交易

而在安卓客户端中，一些 AI 应用支持 Google Play 应用内订阅。

此时，实际支付流程通常是：

AI 应用发起订阅
        ↓
Google Play 显示订阅价格
        ↓
用户通过 Google Play 付款
        ↓
Google Play 将订阅状态同步给应用

也就是说，银行卡主要绑定在 Google Play 付款资料中，而不是直接绑定到 ChatGPT、Gemini 或 Grok 的官网账户。

这种方式的优势是：

通过官方应用商店付款
不需要使用来历不明的代充平台
可以在 Google Play 中统一管理订阅
可以直接查看续费日期
可以随时取消自动续费
退款和订单记录相对清晰

但最终能否成功，仍取决于 Google Play、发卡银行和应用本身的地区政策。

二、准备一张支持境外支付的信用卡

我更建议使用带有以下标识的信用卡：

Visa
Mastercard

部分全币种信用卡或双币信用卡也可以尝试。

在操作之前，应先通过银行 App 或联系银行客服确认以下功能已经开启：

境外线上支付
无卡支付
外币交易
自动续费
3D Secure 验证
小额境外交易

有些信用卡虽然印有 Visa 或 Mastercard 标识，但默认关闭了境外线上交易，因此绑定或扣款时仍可能失败。

另外还要注意卡片额度。部分平台在绑卡时可能产生一笔很小的预授权验证，之后再自动撤销。

三、准备安卓手机和 Google Play

1. 确认手机支持 Google 服务

打开手机设置，搜索：

Google

查看是否存在以下功能：

Google 基础服务
Google Play 服务
Google Play 商店
Google 服务框架

部分国产安卓手机虽然没有预装 Google Play，但系统中可能保留了 Google 基础服务开关。

不同品牌手机的菜单名称可能不同，常见位置包括：

1
2
3

设置
→ 账号与同步
→ Google 基础服务

或者：

1
2
3

设置
→ 应用设置
→ Google 服务

如果手机完全不支持 Google 移动服务，可能需要使用其他支持 Google Play 的安卓设备。

2. 安装或更新 Google Play 商店

可以先在手机自带的应用商店中搜索：

`1`	`Google Play 商店`

同时确认以下组件已经更新：

Google Play 商店
Google Play 服务
Chrome 浏览器
Android System WebView

如果这些组件版本过旧，可能出现登录失败、付款页面无法打开或订阅窗口闪退等问题。

3. 保持网络环境稳定

Google Play 对账号登录、设备环境和付款行为都有风控检测。

操作过程中应尽量保持网络稳定，不要频繁切换：

国家或地区
IP 地址
设备
Google 账号
付款资料

频繁切换环境可能导致：

无法添加付款方式
Google Play 国家或地区异常
付款被拒绝
要求重新验证身份
账号触发临时保护

我更建议使用自己长期稳定使用的网络和 Google 账号进行操作。

四、登录或注册 Google 账号

打开 Google Play 商店，登录自己的 Google 账号。

建议使用长期正常使用的个人账号，而不是刚刚注册、购买或来源不明的账号。

新注册账号如果立刻进行以下操作，可能更容易触发风控：

修改账号地区
添加境外信用卡
高频下载应用
立即购买高价值订阅
短时间内更换多个设备
频繁切换网络位置

因此，账号最好已经有一段正常使用记录。

不建议购买所谓的“成品谷歌账号”，原因包括：

原注册人可能找回账号
恢复邮箱和手机号不属于自己
账号可能曾被多人登录
可能存在历史违规记录
付款信息和身份信息不一致
订阅后仍可能触发安全审查

五、开启 Google 账号两步验证

在添加银行卡和购买订阅之前，我建议先开启两步验证。

操作路径大致如下：

Google Play 商店
→ 点击右上角头像
→ 管理你的 Google 账号
→ 安全性
→ 两步验证

可以选择以下验证方式：

Google 提示
手机短信
身份验证器
安全密钥
备用验证码

我通常会同时保留两种验证方式，避免手机丢失后无法登录账号。

使用身份验证器

可以使用：

Google Authenticator
Microsoft Authenticator
其他兼容 TOTP 的验证器

绑定时，系统通常会显示二维码或密钥。

添加完成后，身份验证器会每隔一段时间生成一个新的六位验证码。输入当前验证码，即可完成绑定。

同时建议保存备用验证码，并放在安全的位置。

六、在 Google Play 中添加信用卡

可以在 Google Play 中进入付款设置。

操作路径通常为：

Google Play 商店
→ 点击右上角头像
→ 付款和订阅
→ 付款方式

如果应用内页面无法完成添加，可以继续点击：

更多付款设置

系统通常会调用 Chrome 浏览器，打开 Google 付款中心。

也可以直接进入 Google 付款中心：

打开 Google 付款中心

填写银行卡信息

根据页面提示填写：

信用卡卡号
到期时间
CVC 或 CVV 安全码
持卡人姓名
账单地址
邮政编码
联系电话

其中，账单地址建议填写与银行记录相符的真实地址。

不要为了改变订阅地区而随意填写陌生住宅、酒店、商场或地图上找到的地址。

虚构账单地址可能造成：

银行地址验证失败
Google 付款资料被暂停
订阅订单被取消
后续付款持续失败
要求提交身份或地址证明
Google 账号受到限制

如果页面不接受当前国家或地区的付款信息，说明该付款资料或订阅渠道可能暂时不支持当前地区。此时应更换官方支持的付款方式，而不是通过虚构信息绕过限制。

七、添加信用卡失败怎么办？

国内信用卡绑定 Google Play 失败并不少见。

可以依次检查以下项目。

1. 确认银行卡支持境外线上交易

通过银行 App 查看银行卡设置，确认已经开启：

境外交易
线上支付
无卡支付
外币支付
自动续费

部分银行还需要单独开启安全锁或调整境外支付限额。

2. 确认卡片余额和额度

即使是订阅付款，也可能先进行小额预授权。

因此，信用卡需要保留一定可用额度。

3. 检查姓名和账单信息

持卡人姓名应尽量与银行系统记录一致。

英文姓名通常可以按照信用卡卡面或银行账单中的拼写填写。

不要频繁更改：

姓名
国家
地址
邮政编码
电话号码

4. 联系发卡银行

如果 Google Play 只显示“付款方式被拒绝”，可以联系银行客服查询是否存在被拦截的境外交易。

向银行说明这是：

`1`	`Google Play 境外线上订阅付款`

让客服确认是否被风控系统拒绝。

5. 不要连续重复提交

短时间内多次添加同一张银行卡，可能触发 Google 的支付风控。

如果连续失败，建议先停止操作，检查原因后再重新尝试，而不是不断点击提交。

八、通过 Google Play 订阅 AI 服务

信用卡成功添加到 Google Play 后，就可以尝试订阅支持应用内购买的 AI 服务。

第一步：从 Google Play 安装官方应用

在 Google Play 中搜索并下载安装需要订阅的应用，例如：

ChatGPT
Google Gemini
Grok

安装前应仔细核对：

应用名称
开发者名称
下载量
应用图标
官方网站
隐私政策

不要安装名称相似的第三方应用。

第二步：登录 AI 账号

打开应用，登录自己的账号。

需要注意：

Google Play 账号和 AI 服务账号通常是两套独立账号。

例如：

1
2

Google Play 账号：负责付款
ChatGPT 账号：负责使用会员权益

两者的邮箱不一定必须相同。

但是在支付前，一定要确认当前登录的是自己真正需要升级的 AI 账号。

如果订阅到了错误的账号，后续转移会员可能会比较麻烦。

第三步：选择升级会员

进入应用的个人中心或设置页面，找到类似选项：

Upgrade
Get Plus
订阅
升级会员
购买高级版

点击后，系统会弹出 Google Play 官方付款窗口。

付款窗口通常会显示：

套餐名称
每月或每年价格
税费
试用期限
下次续费日期
当前付款方式

确认信息无误后，再点击订阅。

第四步：确认订阅状态

付款成功后，可以在 Google Play 中查看：

Google Play 商店
→ 头像
→ 付款和订阅
→ 订阅

这里通常可以看到：

当前订阅
订阅价格
下次续费日期
付款方式
取消订阅入口

同时回到 AI 应用中，检查高级会员权益是否已经生效。

部分订单可能需要等待几分钟才能同步。

九、Google Play 账号与 AI 账号的关系

很多人会误以为，只要在某个 Google 账号中付款，会员就一定跟着 Google 账号走。

实际上，通常涉及三层关系：

Google Play 账号
→ 负责付款和订单记录

AI 应用账号
→ 接收会员权益

手机中的应用安装来源
→ 决定由哪个应用商店处理购买

订阅前需要同时确认：

Google Play 当前登录的是哪个账号。
AI 应用当前登录的是哪个账号。
Google Play 付款窗口显示的是哪张银行卡。
订阅页面显示的是哪个套餐。

只要其中一个环节弄错，就可能出现：

扣款成功但会员开错账号
应用找不到订阅
恢复购买失败
付款时调用了另一个 Google 账号
无法判断订阅由谁管理

十、如何切换用于付款的 Google 账号？

如果手机中同时登录了多个 Google 账号，应用内付款时可能会调用错误的付款账号。

可以先打开 Google Play 商店，点击右上角头像，切换到需要用于付款的账号。

如果应用仍然调用原来的账号，可以尝试：

卸载目标 AI 应用。
在 Google Play 中切换到正确账号。
重新从 Google Play 安装应用。
登录需要升级的 AI 账号。
再次打开订阅页面。

仍然无法切换时，可以检查手机中的 Google 账号列表：

1
2
3

设置
→ 账号与同步
→ Google

暂时移除不需要用于付款的 Google 账号，可能有助于减少账号调用混乱。

移除账号前，应先确认：

已经保存密码
两步验证方式可用
联系人和数据已经同步
不会影响其他应用

十一、ChatGPT 订阅注意事项

通过 Google Play 订阅 ChatGPT 后，会员权益通常归属于付款时登录的 OpenAI 账号。

订阅前应确认：

当前 ChatGPT 账号正确
Google Play 付款账号正确
选择的是所需套餐
页面价格和续费周期正确

如果付款成功但会员没有立即生效，可以尝试：

重新启动 ChatGPT App
退出后重新登录
检查 Google Play 订单是否成功
使用应用内的恢复购买功能
联系官方支持并提供 Google Play 订单信息

不要在订单状态不明时重复购买，以免产生多笔扣款。

十二、Gemini 订阅注意事项

Gemini 的高级服务可能与 Google One 或特定 Google AI 套餐关联。

订阅前需要仔细确认：

购买的是哪一个 Google 套餐
是否包含 Gemini 高级功能
是否包含云存储空间
优惠期结束后的正式价格
当前 Google 账号是否符合购买条件
所在地区是否支持该套餐

由于 Gemini 与 Google 账号体系绑定较深，付款账号与实际使用账号通常应保持一致，以免会员权益出现在另一个 Google 账号中。

十三、Grok 订阅注意事项

Grok 的订阅入口、套餐名称和权益可能随着官方产品调整而变化。

订阅时应重点查看：

是通过 Grok App 订阅，还是通过其他平台订阅
套餐是否包含完整模型权限
是否有使用次数限制
是否自动续费
会员权益绑定到哪个账号
Google Play 订单能否在其他平台使用

确认清楚后再付款，不要只根据应用中的宣传按钮直接购买。

十四、Claude 订阅需要更加谨慎

Claude 对账号地区、网络环境、付款来源和使用行为可能有较严格的风控。

如果官方应用或当前地区没有明确提供订阅入口，不建议通过频繁切换地区、购买账号或虚构账单资料的方式强行订阅。

这类操作可能导致：

付款失败
账号验证
订阅被取消
账号功能受限
无法获得退款

更稳妥的方式是使用 Claude 官方在所在地区明确支持的付款渠道，并保持账号信息、付款信息和使用环境真实一致。

十五、Google Play 订阅不等于 API 充值

本文介绍的是 AI 应用客户端中的会员订阅，不适用于 API 账户充值。

两者的区别是：

应用会员订阅

主要用于：

ChatGPT App
Gemini App
Grok App
其他支持 Google Play 应用内购买的客户端

付款渠道可能是：

`1`	`Google Play`

API 费用

主要用于：

程序调用模型
网站集成 AI
自动化工具
开发测试
按 Token 计费

API 通常需要直接在对应平台的开发者后台添加付款方式。

Google Play 中绑定的信用卡，一般不能直接用于以下平台的 API 账单：

OpenAI API
Anthropic API
Google AI Studio 或 Google Cloud API
xAI API

API 平台是否接受国内信用卡，需要以各平台当前的支付政策和银行卡风控结果为准。

十六、如何取消自动续费？

通过 Google Play 订阅后，可以在以下位置取消：

Google Play 商店
→ 点击头像
→ 付款和订阅
→ 订阅
→ 选择对应服务
→ 取消订阅

取消自动续费后，通常不会立即失去会员权益。

一般可以继续使用到当前账单周期结束，具体时间以订阅页面显示为准。

需要注意：

卸载 App 不等于取消订阅。
退出 AI 账号不等于取消订阅。
删除银行卡不一定会自动取消订阅。
删除 Google 账号前应先处理所有订阅。
取消后应确认页面显示“不再续费”或明确的到期日期。

十七、我的实际建议

如果只有国内信用卡，我建议按照以下顺序尝试：

优先检查 AI 服务官网是否支持当前银行卡。
官网付款失败后，再查看官方安卓 App 是否支持 Google Play 订阅。
使用自己的长期 Google 账号。
使用真实的持卡人和账单信息。
提前开启银行卡境外线上支付。
付款前确认 AI 账号和 Google Play 账号。
保存订单邮件和 Google Play 订单号。
订阅成功后检查自动续费日期。
不使用来源不明的代充平台。
不购买无法完全控制的成品账号。

这套方式的核心并不是绕过支付限制，而是在官方允许的范围内，尝试使用 Google Play 提供的应用内订阅渠道。

不同银行、账号和地区的结果可能不一样。遇到付款失败时，应先查清楚是银行拒付、Google 风控还是应用地区限制，再决定下一步操作。

总结

使用国内 Visa 或 Mastercard 信用卡，通过 Google Play 订阅 ChatGPT、Gemini、Grok 等 AI 服务，在部分情况下是可行的。

它的主要优势包括：

使用官方应用商店付款
不需要向第三方代充平台提供账号
订阅记录清晰
自动续费可以统一管理
可以随时取消订阅
相比不明来源的虚拟卡更容易控制风险

但它并不是百分之百成功的方法。

银行卡类型、发卡银行、Google 账号地区、应用支持范围和支付风控，都会影响最终结果。

我更建议把账号安全和长期稳定放在第一位，使用真实资料、官方应用和官方付款渠道。只要订阅入口、账号地区或付款信息存在明显冲突，就不要急着反复尝试，更不要通过虚构地址或购买账号的方式强行绕过限制。

HANDOFF.md 是什么？让新 AI 会话无缝接手旧任务

Fri, 24 Jul 2026 17:39:00 +0800

在 Codex、Claude Code 或 Cursor 中连续工作很久后，常见问题是：

对话上下文快满了；
AI 开始忘记早期要求；
新建会话后又要重新解释项目；
已完成的工作、踩过的坑和后续计划容易丢失。

HANDOFF.md 就是一份 AI 交接文档。

它把当前会话中的关键信息整理成 Markdown 文件，让下一次新会话先阅读这份文档，再继续工作。

使用后有什么效果？

它不能增加模型额度，也不能让 AI 永久记住所有内容，但可以明显改善长任务的连续性：

新会话更快理解项目；
减少重复介绍背景；
保留已经完成的工作；
记录当前卡点和错误尝试；
避免新 AI 重复踩坑；
让 Codex、Claude Code、Cursor 之间也能互相交接。

这种方法本质上是把聊天记录中最重要的信息，压缩成一份可长期保存的项目说明。已有 handoff 工具和实践也采用类似思路：把目标、决定、当前状态、关键文件和下一步写入 Markdown，再由新会话读取。

什么时候使用？

比较适合以下情况：

当前对话即将达到上下文上限；
一个项目需要分多次完成；
准备关闭 Codex 或 Claude Code；
想换一个 AI 工具继续处理；
当前 AI 开始遗忘前面的要求；
任务中已经做过很多测试和修改。

不要等到 AI 已经严重混乱后再生成，最好在当前会话仍能准确回忆全部过程时使用。

可直接复制的交接指令

本次对话即将结束，请在当前项目根目录生成一份交接文档，并命名为 HANDOFF.md。

文档必须包含以下内容：

1. 整体任务目标
2. 用户的核心要求和限制条件
3. 当前项目环境、技术栈和目录位置
4. 现阶段已经完成的工作
5. 已修改、新增或删除的关键文件
6. 当前尚未完成的工作
7. 当前遇到的卡点、报错和阻碍
8. 已经尝试过但没有成功的方法
9. 本轮对话中踩过的坑
10. 后续必须规避的雷区
11. 后续完整执行方案
12. 下一步最优先执行的具体任务
13. 验证工作是否完成的方法
14. 运行、测试、构建和部署命令
15. 其他新会话必须知道的重要信息

要求：

- 不要只写简单摘要。
- 必须写清楚为什么这样做，以及当前结果是什么。
- 涉及文件时写出完整或相对路径。
- 涉及命令时使用代码块完整记录。
- 涉及报错时保留关键报错内容。
- 明确区分已经确认的事实、推测和待验证事项。
- 不要隐瞒失败过程和未解决问题。
- 整篇文档必须做到：即使新会话完全没有当前聊天记录，也能仅通过 HANDOFF.md 理解项目并继续工作。
- 生成完成后，请检查文档是否遗漏关键要求，不要继续执行其他任务。

新会话中发送的指令

请先完整读取当前项目根目录中的 HANDOFF.md。

读取后不要立即修改代码，先完成以下工作：

1. 总结当前项目目标；
2. 说明已经完成的工作；
3. 列出尚未完成的任务；
4. 指出当前卡点和需要规避的雷区；
5. 给出你准备执行的下一步方案。

确认已经正确理解 HANDOFF.md 后，再继续处理项目。

使用时需要注意

HANDOFF.md 的质量取决于当前 AI 是否真正掌握项目状态。

如果交接文档只写“已经修改页面，后续继续优化”，新会话仍然无法接手。好的交接文档应该写清：

改了哪个文件；
为什么修改；
修改后的结果；
哪个方案失败；
下一步具体做什么；
怎样判断任务完成。

另外，交接文档只是记录状态，不会自动保存未提交代码。重要项目仍然需要配合 Git 提交、测试和备份。

总结

这段指令的真正价值，不是让 AI 获得永久记忆，而是人为建立一套可靠的“项目交接机制”。

对于需要多轮完成的网站开发、代码修复、服务器配置和大型项目，它可以减少大量重复沟通，并降低新会话错误接手的风险。

Chrome DevTools MCP：让 AI 直接操作浏览器调试网站

Fri, 24 Jul 2026 17:28:00 +0800

以前使用 Codex、Claude Code 或 Cursor 修改网页时，AI 通常只能查看代码，却不知道网页实际运行后是什么样子。

Chrome DevTools MCP 可以把 AI 编程助手连接到真实的 Chrome 浏览器，让 AI 像开发者一样打开网页、点击按钮、查看报错并分析网站性能。它由 Chrome DevTools 团队维护。

它能做什么？

安装后，AI 可以直接：

打开并操作网页；
点击按钮、填写表单；
查看 Console 控制台报错；
分析接口和网络请求；
截取网页图片；
检查页面加载速度；
分析 LCP、INP、CLS 等性能指标；
修改代码后自动打开浏览器验证结果。

简单理解：

它相当于给 AI 安装了一双“浏览器眼睛”，让 AI 不再只看代码猜问题。

最简单的安装方法

使用前需要安装：

最新稳定版 Chrome；
Node.js LTS；
npm。

Codex 安装

在终端执行：

`1`	`codex mcp add chrome-devtools -- npx chrome-devtools-mcp@latest`

Claude Code 安装

`1`	`claude mcp add chrome-devtools --scope user npx chrome-devtools-mcp@latest`

Cursor 安装

打开：

`1`	`Cursor Settings → MCP → New MCP Server`

填入：

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": ["-y", "chrome-devtools-mcp@latest"]
    }
  }
}

这些都是项目官方提供的安装方式。

如何测试？

安装完成并重启 AI 编程工具，然后输入：

`1`	`使用 Chrome DevTools 检查 https://developers.chrome.com 的性能。`

如果配置正确，AI 会自动打开 Chrome，并开始记录网页性能数据。浏览器通常要等 AI 第一次调用工具时才会自动启动。

适合哪些人？

它特别适合：

使用 AI 开发网站；
排查网页打不开或按钮失效；
检查手机端布局；
分析接口请求失败；
优化网站加载速度；
让 AI 自动验证修改结果。

需要注意，Chrome DevTools MCP 可以读取和操作浏览器中的网页内容，因此不要让它连接到包含隐私、密码或敏感账户信息的浏览器页面。

项目地址

https://github.com/ChromeDevTools/chrome-devtools-mcp

Graphify：把整个项目变成一张 AI 能看懂的知识图谱

Fri, 24 Jul 2026 13:45:00 +0800

使用 Codex、Claude Code 或 Cursor 分析大型项目时，AI 往往需要反复搜索文件、读取代码，既慢又容易浪费上下文。

Graphify 的作用，就是把项目中的代码、文档、配置、PDF 和图片整理成一张“知识图谱”。图谱会记录文件、函数、类、调用关系和模块之间的联系，让 AI 不必每次从头翻阅整个项目。

它有什么用？

安装 Graphify 后，可以帮助 AI：

快速理解项目结构；
查找函数和类之间的关系；
分析修改代码会影响哪些位置；
查看两个模块之间的调用路径；
减少反复读取大量无关文件。

代码分析主要在本地通过 Tree-sitter 完成，不需要把源代码上传给第三方模型。Graphify 生成的每条关系还会标记为“源码中直接提取”或“工具推断”，方便判断结果是否可靠。

最简单的安装方法

先安装 uv，然后在终端执行：

1
2

uv tool install graphifyy
graphify install

注意：Python 安装包的名称是 graphifyy，有两个字母 y，但安装后的命令仍然是 graphify。

安装完成后，打开 Codex、Claude Code 或 Cursor，在项目目录中输入：

`1`	`/graphify .`

Graphify 会自动分析当前项目，并生成：

graphify-out/
├── graph.html
├── GRAPH_REPORT.md
└── graph.json

其中：

graph.html：可以在浏览器中查看项目关系图；
GRAPH_REPORT.md：项目结构和重点说明；
graph.json：供 AI 后续查询的完整知识图谱。

如何使用？

生成图谱后，可以让 AI 查询：

`1`	`请使用 Graphify 解释这个项目的核心结构。`

也可以在终端中使用：

`1`	`graphify explain "UserService"`

查询两个模块之间的关系：

`1`	`graphify path "UserService" "Database"`

Graphify 更适合文件较多、结构较复杂的项目。对于只有几个文件的小项目，直接让 AI 阅读代码通常已经足够。

项目地址

https://github.com/Graphify-Labs/graphify

jCodeMunch MCP 使用教程：让 Codex、Claude Code 少读废代码，降低 Token 消耗

Fri, 24 Jul 2026 10:23:00 +0800

使用 Codex、Claude Code 或 Cursor 编写项目时，你可能遇到过这样的情况：

明明只需要修改一个函数，AI 却读取了整个文件；
为了寻找一段代码，AI 连续扫描几十个文件；
项目越大，分析速度越慢；
代码还没改多少，上下文或使用额度却消耗了很多；
AI 读了大量无关代码，反而开始答非所问。

jcodemunch-mcp 正是为了解决这类问题而出现的。

它不会替代 Codex，也不是一个新的 AI 编程模型。它更像是给 AI 编程助手安装了一套“代码目录和精准检索系统”，让 AI 在分析项目时，不必每次都从头翻阅整个代码仓库。

本文将从零开始说明：

jCodeMunch MCP 是什么；
它有什么实际作用；
它是怎样减少 Token 消耗的；
哪些用户适合安装；
如何在 Windows、macOS 和 Linux 上安装；
如何连接 Codex CLI、Claude Code 和 Cursor；
安装后应该怎样使用；
常见问题及注意事项。

一、jCodeMunch MCP 是什么

jCodeMunch MCP 是一个面向 AI 编程助手的代码检索工具。

它会先扫描并建立项目索引，然后把代码中的内容拆分成更容易检索的结构，例如：

函数；
类；
方法；
常量；
导入关系；
文件结构；
类的继承关系；
某个函数被哪些地方调用；
修改某段代码可能影响哪些位置。

当 Codex 或 Claude Code 需要查找代码时，jCodeMunch 可以只返回真正相关的函数或类，而不是把整个文件全部发送给 AI。

项目官方将它定义为一个“本地优先的结构化代码检索系统”。它使用 tree-sitter 分析代码的抽象语法树，并通过 MCP 协议把检索能力提供给 Codex、Claude Code、Cursor 等工具。

简单理解：

普通方式是让 AI 一本一本地翻书；jCodeMunch 则先为所有书建立目录，让 AI 直接翻到需要的那一页。

二、MCP 又是什么

MCP 的全称是：

`1`	`Model Context Protocol`

中文可以理解为“模型上下文协议”。

它是一种让 AI 调用外部工具的标准接口。

例如，支持 MCP 的 AI 编程工具可以连接：

文件系统；
数据库；
GitHub；
浏览器；
搜索引擎；
项目管理工具；
代码索引工具。

jCodeMunch 本身就是一个 MCP Server，也就是“向 AI 提供代码检索能力的服务”。

安装完成后，大致关系如下：

Codex / Claude Code / Cursor
             ↓
          MCP 协议
             ↓
       jCodeMunch MCP
             ↓
      本地项目代码索引

你仍然是在 Codex 或 Claude Code 中提问，只是 AI 在需要寻找代码时，可以调用 jCodeMunch 提供的工具。

三、它解决了什么问题

1. 避免读取整个大文件

假设项目中有一个 700 行的文件，而你只需要修改其中一个 30 行的函数。

普通 AI 编程流程可能是：

读取整个 700 行文件
↓
从中寻找目标函数
↓
理解上下文
↓
修改其中 30 行

使用 jCodeMunch 后，可以变成：

搜索函数名称
↓
只取得目标函数的 30 行代码
↓
理解并修改

项目文档给出的典型示例是：编辑一个大文件中的单个函数时，可以从读取约 700 行缩小到读取约 30 行。不过实际节省程度取决于项目结构和具体任务。

2. 更快找到代码位置

当你问：

`1`	`用户登录验证写在哪里？`

普通方式可能会在整个项目里搜索：

login
auth
token
user
session

然后打开多个文件逐个判断。

jCodeMunch 可以直接从函数、类和方法的索引中寻找相关符号，例如：

AuthService.login
verifyToken
UserSession
authenticateRequest

这样返回的结果通常更加集中。

3. 帮助理解陌生项目

当你第一次接触一个 GitHub 项目时，经常不知道：

入口文件在哪里；
主要模块有哪些；
API 路由放在哪里；
数据库逻辑在哪一层；
某个类被哪些文件使用；
修改某个函数会影响什么。

jCodeMunch 可以先提供仓库结构、文件概要和符号列表，再按需要提取具体代码。

这比一开始就让 AI 阅读整个项目更加节省上下文。

4. 辅助重构和影响范围分析

除了查找函数，它还可以帮助 AI 分析：

`1`	`修改这个函数后，可能影响哪些调用位置？`

或者：

`1`	`这个类被哪些模块引用？`

项目提供了依赖关系、导入者、调用关系和影响范围等检索能力。这是普通文本搜索不容易直接完成的事情。

5. 减少无关代码干扰

上下文并不是越多越好。

当 AI 同时看到大量无关代码时，可能出现：

抓错重点；
混淆同名函数；
根据旧代码做出判断；
修改不相关文件；
输出内容牛头不对马嘴。

精确地提供少量相关代码，有时比一次性塞入整个仓库更有利于模型判断。

四、它真的能节省 95% Token 吗

jCodeMunch 项目宣传可以将代码探索过程中的 Token 消耗降低 95% 以上，并公开了一套基准测试。

在项目当前公开的测试中，作者使用 Express、FastAPI 和 Gin 三个代码仓库，执行了 15 次代码检索任务。测试比较了：

将仓库源代码全部读取；
先搜索符号，再读取最相关的三个符号。

该测试报告的平均 Token 降幅为 99.6%。

不过需要正确理解这个数字。

这项测试主要衡量的是：

“精准检索代码”与“读取全部源代码”之间的 Token 差异。

它并不直接代表：

你的 Codex 总额度一定减少 99.6%；
每次编程任务都能减少 99.6%；
AI 输出内容的 Token 也会同时减少；
最终答案质量一定提升；
所有类型的项目都能达到同样效果。

项目自己的测试方法也明确说明，它没有测量完整任务质量、总延迟或端到端完成效果，而且测试查询数量较少，不同项目的实际结果可能不同。

因此，更准确的说法是：

在大型、结构清晰的代码仓库中，当 AI 需要查找某个函数、类或模块时，jCodeMunch 有机会显著减少读取代码所消耗的上下文；但实际节省比例需要根据项目和任务判断。

五、哪些人适合使用

jCodeMunch 比较适合以下情况。

适合使用

经常使用 Codex CLI、Claude Code 或 Cursor；
项目中有很多文件；
单个代码文件比较长；
经常让 AI 分析陌生 GitHub 项目；
经常进行局部修改；
经常寻找函数、类、接口或调用关系；
使用额度有限，希望减少无关扫描；
需要在大型项目中进行重构；
同一个项目会被 AI 反复分析。

暂时没有必要使用

项目只有几个文件；
每个文件只有几十行；
只是偶尔让 AI 写一小段独立代码；
任务本身就必须阅读完整文件；
AI 主要用于写文章，而不是分析代码；
当前使用的客户端不支持 MCP。

例如，一个只有三个 HTML 文件的小网站，安装 jCodeMunch 的意义可能不大。

但对于 Next.js、Vue、Laravel、Django、WordPress 插件或包含大量模块的工具项目，它更容易发挥作用。

六、支持哪些语言和工具

根据项目当前说明，jCodeMunch 支持 70 多种语言，包括：

Python；
JavaScript；
TypeScript；
Go；
Rust；
Java；
C；
C++；
C#；
PHP；
Ruby；
Swift；
Kotlin。

它通过 tree-sitter 对这些语言进行代码结构分析。

支持的 MCP 客户端包括：

Codex CLI；
Claude Code；
Claude Desktop；
Cursor；
VS Code；
Continue；
Windsurf；
Cline；
Roo Code；
Gemini CLI；
Qwen Code；
其他支持 MCP 的客户端。

具体支持情况可能随着版本更新而变化，应以项目最新 README 为准。

七、安装前需要准备什么

建议先准备：

1
2
3

Python
终端工具
支持 MCP 的 AI 编程客户端

检查 Python

打开 PowerShell、Windows Terminal 或 macOS/Linux 终端，输入：

`1`	`python --version`

有些系统需要输入：

`1`	`python3 --version`

看到类似下面的结果，说明 Python 已经安装：

`1`	`Python 3.12.4`

然后检查 pip：

`1`	`pip --version`

或者：

`1`	`python -m pip --version`

如果提示找不到 python 或 pip，需要先安装 Python，并在安装时勾选：

`1`	`Add Python to PATH`

八、最简单的安装方法

官方目前提供了自动初始化命令。它可以尝试检测 Claude Code、Claude Desktop、Cursor、Windsurf 和 Continue，并自动写入对应配置。

打开终端，执行：

`1`	`pip install jcodemunch-mcp`

安装完成后执行：

`1`	`jcodemunch-mcp init`

程序会进入交互式设置流程，可能会询问：

要为哪些 MCP 客户端安装；
是否添加使用规则；
是否安装自动更新索引的 Hook；
是否立即索引当前项目；
是否检查 AI 配置中的 Token 浪费。

按照终端提示选择即可。

完成后，重新启动 Codex、Claude Code、Cursor 或对应编辑器。

先查看但不修改配置

担心自动初始化修改配置，可以先执行：

`1`	`jcodemunch-mcp init --dry-run`

它会显示准备进行哪些操作，但不会真正修改文件。

也可以运行演示模式：

`1`	`jcodemunch-mcp init --demo`

这两项功能适合第一次接触 MCP 的用户。

九、Windows 安装建议

Windows 用户可以在 PowerShell 中执行：

`1`	`python -m pip install -U jcodemunch-mcp`

安装后检查：

`1`	`jcodemunch-mcp --version`

如果能够看到版本号，继续执行：

`1`	`jcodemunch-mcp init`

提示“找不到 jcodemunch-mcp”

这是 Windows 上比较常见的问题，通常是 Python 的 Scripts 目录没有加入 PATH。

先执行：

`1`	`python -m jcodemunch_mcp --help`

如果这个命令可以运行，说明包已经安装，只是系统找不到独立的可执行文件。

可以在 MCP 配置中使用：

{
  "command": "python",
  "args": ["-m", "jcodemunch_mcp"]
}

也可以查找安装位置：

`1`	`where.exe jcodemunch-mcp`

如果仍然找不到，执行：

`1`	`python -m site --user-base`

输出目录下面通常会有一个 Scripts 文件夹，需要将该目录加入 Windows 的 PATH。

十、在 Claude Code 中安装

方法一：自动设置

执行：

1
2

pip install jcodemunch-mcp
jcodemunch-mcp init

初始化程序会尝试自动发现 Claude Code 并写入配置。

完成后重启 Claude Code，然后输入：

/mcp

查看是否出现：

`1`	`jcodemunch`

方法二：手动添加

如果已经使用 pip 安装，可以运行：

`1`	`claude mcp add -s user jcodemunch jcodemunch-mcp`

这里的：

-s user

表示把它安装到用户级别，而不是只在当前项目中使用。

如果采用 uvx，可以使用：

`1`	`claude mcp add -s user jcodemunch uvx jcodemunch-mcp`

项目文档提醒，若 Windows 无法找到程序，可以把命令替换为实际的 jcodemunch-mcp.exe 绝对路径。

十一、在 Cursor 中安装

最省事的方法仍然是：

1
2

pip install jcodemunch-mcp
jcodemunch-mcp init

如果自动识别失败，可以在 Cursor 的 MCP 配置中添加：

{
  "mcpServers": {
    "jcodemunch": {
      "command": "uvx",
      "args": ["jcodemunch-mcp"]
    }
  }
}

没有安装 uv，也可以使用 Python：

{
  "mcpServers": {
    "jcodemunch": {
      "command": "python",
      "args": ["-m", "jcodemunch_mcp"]
    }
  }
}

保存后彻底关闭并重新打开 Cursor。

注意，不只是关闭项目窗口，而是要完全退出 Cursor 进程后重新启动。

十二、在 Codex CLI 中安装

Codex CLI 的配置方式和 Cursor 不同。

Codex 使用的是 TOML 配置文件，通常位于：

`1`	`~/.codex/config.toml`

Windows 中一般对应：

`1`	`C:\Users\你的用户名\.codex\config.toml`

推荐方法：使用独立虚拟环境

项目当前文档建议 Codex CLI 不要在首次连接时直接使用 uvx，因为首次运行产生的安装输出有可能干扰 MCP 的 JSON-RPC 握手。更稳妥的方式是先把 jCodeMunch 安装到虚拟环境，再让 Codex 直接调用可执行文件。

macOS 或 Linux

进入准备使用的目录：

`1`	`python3 -m venv .venv`

安装：

`1`	`.venv/bin/pip install -U jcodemunch-mcp`

测试：

`1`	`.venv/bin/jcodemunch-mcp --help`

然后编辑：

`1`	`~/.codex/config.toml`

加入：

1
2

[mcp_servers.jcodemunch]
command = "/你的绝对路径/.venv/bin/jcodemunch-mcp"

这里一定要使用真实的绝对路径，不要直接照抄示例。

Windows

在 PowerShell 中创建虚拟环境：

`1`	`python -m venv C:\Tools\jcodemunch-venv`

安装：

`1`	`C:\Tools\jcodemunch-venv\Scripts\python.exe -m pip install -U jcodemunch-mcp`

测试：

`1`	`C:\Tools\jcodemunch-venv\Scripts\jcodemunch-mcp.exe --help`

然后打开：

`1`	`C:\Users\你的用户名\.codex\config.toml`

加入：

1
2

[mcp_servers.jcodemunch]
command = "C:\\Tools\\jcodemunch-venv\\Scripts\\jcodemunch-mcp.exe"

TOML 中的 Windows 路径建议使用双反斜杠：

\\

保存配置后，彻底关闭 Codex CLI，再重新启动。

简单但不优先推荐的 Codex 配置

部分环境也可以使用：

1
2
3

[mcp_servers.jcodemunch]
command = "uvx"
args = ["jcodemunch-mcp"]

但根据项目当前说明，Codex 对 MCP 启动时的标准输出比较严格，因此预先安装并指向真实可执行文件通常更加稳定。

十三、安装完成后如何建立项目索引

只连接 MCP 还不够，jCodeMunch 必须先知道你要分析哪个项目。

最简单的方法是进入项目目录：

`1`	`cd 你的项目目录`

然后在 Codex 或 Claude Code 中提出：

`1`	`请使用 jCodeMunch 检查当前项目是否已经建立索引。如果没有，请为当前项目建立索引。`

也可以要求它先解析当前目录：

`1`	`请先使用 resolve_repo 识别当前项目。如果项目尚未建立索引，请调用 index_folder。`

如果初始化时选择了：

`1`	`Index current project`

当前项目可能已经建立了索引。

索引的作用

第一次建立索引时，jCodeMunch 会：

扫描项目文件；
识别代码语言；
使用 tree-sitter 解析代码；
提取函数、类、方法等符号；
保存文件结构和代码位置；
建立可供 AI 查询的本地索引。

之后再次查询相同项目时，不必重新从头解析全部内容。

十四、如何确认它已经正常工作

可以在 AI 编程工具中输入：

`1`	`请使用 jCodeMunch 显示当前项目的仓库概要。`

或者：

`1`	`请使用 jCodeMunch 列出当前项目的主要目录、模块、类和函数。`

还可以测试：

`1`	`请使用 search_symbols 查找项目中的登录验证函数，不要使用普通的全文文件扫描。`

能够返回结构化的函数、类或文件结果，说明它已经工作。

在 Claude Code 中，还可以输入：

/mcp

确认 jcodemunch 状态是否为已连接。

十五、安装后一定要告诉 AI 使用它

这是最容易被忽略的一步。

MCP 安装成功，只代表 AI“可以使用”jCodeMunch，并不代表 AI“每次都会主动使用”。

很多 AI 编程助手仍然可能优先使用自己的：

Read；
Grep；
Glob；
Bash；
全文件扫描。

项目文档也明确提醒，如果没有添加使用规则，AI 可能继续使用原生文件工具，而不调用 jCodeMunch。

可以在项目的 AGENTS.md、CLAUDE.md 或其他项目指令文件中加入：

## Code Exploration Policy

分析、搜索或理解项目代码时，优先使用 jCodeMunch MCP。

- 查找函数、类或方法时，优先使用 search_symbols。
- 查看文件结构时，优先使用 get_file_outline。
- 查看项目结构时，优先使用 get_repo_outline 或 get_file_tree。
- 修改具体函数前，优先使用 get_symbol_source 获取目标代码。
- 只有在确实需要完整文件上下文时，才读取整个文件。
- 如果项目尚未建立索引，先使用 resolve_repo 和 index_folder。

如果是 Codex，可以把类似规则写入项目根目录的：

`1`	`AGENTS.md`

这样 Codex 每次进入项目时，都更容易遵守这套代码检索方式。

还可以直接在对话中说：

`1`	`本次任务必须优先使用 jCodeMunch 搜索符号和读取目标代码，不要一开始就扫描整个项目。`

十六、推荐的实际使用提示词

1. 第一次了解项目

`1`	`请先使用 jCodeMunch 获取项目概要、主要目录和核心模块，不要直接读取所有文件。然后用小白能够理解的语言说明这个项目是怎样运行的。`

2. 查找功能位置

`1`	`请使用 jCodeMunch 查找用户登录、Token 验证和权限检查相关的函数或类，并告诉我它们分别位于哪些文件中。`

3. 修改一个函数

`1`	`请使用 jCodeMunch 查找负责文件上传的函数，只读取目标函数及必要的调用上下文。确认影响范围后再修改，不要扫描无关文件。`

4. 分析报错

`1`	`请根据下面的报错信息，使用 jCodeMunch 查找相关符号、调用方和异常处理逻辑，然后判断最可能的问题位置。`

5. 分析修改影响

`1`	`请使用 jCodeMunch 分析修改 UserService.updateProfile 后可能影响的调用位置、接口和测试文件。`

6. 接手陌生 GitHub 项目

`1`	`请使用 jCodeMunch 为这个项目建立索引，然后依次说明项目入口、目录结构、核心模块、数据流和运行方法。不要一次读取整个仓库。`

十七、代码修改后索引会不会过期

会。

如果文件内容已经修改，但索引仍然保留旧版本，AI 可能检索到过期代码。

jcodemunch-mcp init 可以选择安装自动化 Hook，例如：

修改文件后自动重新索引；
在读取大文件前提醒使用精准检索；
在上下文压缩前保存会话信息。

这些功能在 Claude Code 中支持得相对完整。自动初始化程序也可以选择索引当前项目和安装相关 Hook。

对于没有对应 Hook 的编辑器，可以：

使用 VS Code 扩展进行保存后重新索引；
修改重要文件后让 AI 重新索引；
重新运行项目索引命令；
在开始新任务前检查索引是否过期。

项目本身也支持增量索引，不一定每次都需要完整扫描整个仓库。

十八、是否需要 API Key

基础代码索引和符号检索不一定需要 AI API Key。

不配置额外模型时，jCodeMunch 仍然可以根据：

函数签名；
类名称；
方法名称；
文件位置；
代码结构；

生成基础索引。

如果需要更强的语义搜索或 AI 生成摘要，可以安装额外组件。

本地语义搜索

`1`	`pip install "jcodemunch-mcp[local-embed]"`

然后下载本地模型：

`1`	`jcodemunch-mcp download-model`

根据项目文档，该模型下载大小约为 23MB，首次下载后可以在本地运行，不需要每次调用网络 API。

OpenAI 兼容摘要

`1`	`pip install "jcodemunch-mcp[openai]"`

Claude 摘要

`1`	`pip install "jcodemunch-mcp[anthropic]"`

Gemini 摘要

`1`	`pip install "jcodemunch-mcp[gemini]"`

这些属于增强功能，不是第一次安装必须完成的步骤。

对于小白，建议先只安装基础版本：

`1`	`pip install jcodemunch-mcp`

确认基础功能正常后，再考虑语义搜索和 AI 摘要。

十九、隐私和代码安全

jCodeMunch 采用“本地优先”架构，索引和代码缓存主要保存在本地。项目架构文档表示，它会保存符号元数据、原始文件缓存和代码字节位置，以便进行精准提取。

但需要注意：

安装第三方工具前，应自行检查项目代码和许可证；
如果启用了 OpenAI、Claude 或 Gemini 摘要，相关代码摘要可能会发送给对应 API；
本地嵌入模式下载模型后可以在本机推理；
不要把 API Key 直接提交到 GitHub；
公司机密项目应先确认企业安全政策；
不要轻易安装不需要的全部扩展依赖。

项目配置文档显示，基础包不会自动引入远程 AI 服务；启用不同的扩展后，才可能连接 Anthropic、Google 或 OpenAI 等外部服务。

二十、许可证需要特别注意

jCodeMunch 并不是传统意义上完全不受限制的 MIT 开源项目。

项目当前采用自己的双用途许可证：

个人、非商业用途免费；
商业用途需要购买许可证；
不能随意改名、重新包装并发布到公共软件包仓库；
修改和再分发时还需要遵守项目许可证中的其他条件。

因此：

个人学习、个人项目可以按照许可证免费使用；
用于公司业务、收费项目或商业开发前，应阅读完整许可证；
不要只看到 GitHub 仓库是公开的，就默认可以无限制商业使用。

许可证条款可能变化，正式商用前应以仓库中的最新 LICENSE 文件为准。

二十一、常见问题

1. 安装后 AI 还是一直读取完整文件

原因通常不是安装失败，而是 AI 没有被要求使用它。

处理方法：

在 AGENTS.md 或 CLAUDE.md 中添加使用规则；
在提示词中明确要求优先调用 jCodeMunch；
检查 MCP 是否处于连接状态；
确认当前项目已经建立索引。

2. 提示 `jcodemunch-mcp is not recognized`

说明系统找不到可执行文件。

先试：

`1`	`python -m jcodemunch_mcp --help`

然后将 MCP 配置改为：

{
  "command": "python",
  "args": ["-m", "jcodemunch_mcp"]
}

或者查找 jcodemunch-mcp.exe 的真实路径并使用绝对路径。

3. Codex 启动时卡住

不要优先使用首次运行的 uvx。

先把 jCodeMunch 安装到固定虚拟环境，再让：

`1`	`~/.codex/config.toml`

直接指向 jcodemunch-mcp 可执行文件。

这是该项目当前针对 Codex CLI 给出的推荐配置。

4. 建立索引后代码更新了怎么办

让 jCodeMunch重新索引修改过的文件，或者安装自动重新索引 Hook。

5. 小项目有必要安装吗

通常没有必要。

jCodeMunch 的优势主要体现在：

大文件；
多文件；
陌生项目；
频繁查找；
局部修改；
重构分析。

6. 它能增加 Codex 额度吗

不能。

它不会：

修改 Codex 订阅；
增加账户额度；
绕过使用限制；
改变 OpenAI 的计费规则。

它只是尽量减少 AI 在读取和查找代码时产生的无效上下文。

7. 它能保证 AI 不犯错吗

不能。

它改善的是代码检索方式，不是模型本身的推理能力。

AI 仍然可能：

理解错误；
修改错误；
漏掉调用关系；
生成存在漏洞的代码。

重要修改仍应执行：

代码审查
单元测试
构建测试
实际运行验证
Git 版本控制

二十二、如何卸载

使用 pip 安装的，可以执行：

`1`	`pip uninstall jcodemunch-mcp`

然后删除对应客户端中的 MCP 配置。

例如 Codex 的：

`1`	`[mcp_servers.jcodemunch]`

Cursor 或 Claude Desktop 配置中的：

"jcodemunch": {
  "command": "...",
  "args": [...]
}

如果创建了单独的虚拟环境，也可以直接删除该虚拟环境目录。

注意，不要误删整个 Codex、Cursor 或 Claude 的配置文件，只删除 jCodeMunch 对应的配置块。

二十三、是否值得安装

我的判断是：

jCodeMunch MCP 不是所有用户都必须安装，但对于经常使用 Codex、Claude Code 或 Cursor 分析中大型项目的人，它是一个值得尝试的代码上下文优化工具。

它真正的价值，不是让 AI“变得更聪明”，而是让 AI：

少读无关文件；
更快找到目标函数；
只提取必要代码；
更清楚地理解项目结构；
在有限上下文中保留更多有效信息。

对于只有几个文件的小项目，提升可能不明显。

对于包含大量源码、模块和依赖关系的项目，它可能显著改善代码探索过程。

最稳妥的使用方式是：

先安装基础版本
↓
连接一个 MCP 客户端
↓
为一个真实项目建立索引
↓
明确要求 AI 优先使用符号检索
↓
观察 Token、速度和回答质量
↓
再决定是否长期使用

不要只看项目宣传的节省比例，更应该根据自己的项目实际测试。

最小安装流程总结

普通用户

1
2

pip install jcodemunch-mcp
jcodemunch-mcp init

重新启动 AI 编程客户端，然后让它：

`1`	`使用 jCodeMunch 检查并索引当前项目。`

Codex CLI 用户

创建固定虚拟环境：

`1`	`python -m venv .venv`

安装：

`1`	`.venv/bin/pip install -U jcodemunch-mcp`

在 Windows 中对应：

`1`	`.venv\Scripts\python.exe -m pip install -U jcodemunch-mcp`

然后在：

`1`	`~/.codex/config.toml`

中加入：

1
2

[mcp_servers.jcodemunch]
command = "/jcodemunch-mcp可执行文件的绝对路径"

最后，在项目根目录的 AGENTS.md 中加入：

`1`	`分析项目代码时优先使用 jCodeMunch MCP。先搜索符号和文件概要，只在确实需要完整上下文时读取整个文件。`

项目地址：https://github.com/jgravelle/jcodemunch-mcp

完成这些步骤后，jCodeMunch 才算真正融入 Codex 的日常代码分析流程。

Codex 省额度工具包（新手版）

Tue, 21 Jul 2026 18:13:00 +0800

这套文件不会增加 Codex 额度，也不会改变收费标准。它通过限制无关扫描、无关修改、完整测试和重复解释，减少不必要的 Token 与 credits 消耗。

工具包下载

点击下载 Codex 省额度工具包（新手版）

下载完成后，请先解压 ZIP 压缩包，再按照下方步骤安装。

最简单的安装方法

第一步：解压

解压下载的 ZIP 文件。

第二步：复制到项目根目录

把解压后的以下内容复制到你的项目最外层目录：

.agents 文件夹
AGENTS.md
PROJECT_STATUS.md
prompts 文件夹

项目根目录通常是能够看到 package.json、README.md、.git 或源代码文件夹的位置。

复制完成后的结构应类似：

你的项目/
├─ .agents/
│  └─ skills/
│     ├─ project-navigation/
│     ├─ minimal-code-change/
│     ├─ targeted-testing/
│     ├─ diagnose-before-fixing/
│     └─ website-small-task/
├─ prompts/
├─ AGENTS.md
├─ PROJECT_STATUS.md
├─ package.json
└─ src/

Windows 默认可能隐藏以点号开头的文件夹。即使看不到 .agents，只要复制成功即可。可以在资源管理器中开启“查看 → 显示 → 隐藏的项目”。

第三步：编辑 PROJECT_STATUS.md

用记事本或 VS Code 打开 PROJECT_STATUS.md，只填写你知道的内容。不知道的地方可以保留。

也可以在 Codex 中粘贴：

请读取当前项目，并只查看项目根目录、package.json、README.md 和主要源码目录。不要扫描整个仓库。然后帮我填写 PROJECT_STATUS.md，控制在100行以内，不修改其他文件。

第四步：重新打开项目

如果 Codex 已经打开这个项目，请关闭当前 Codex 会话并重新打开项目，使它重新发现 AGENTS.md 和 Skills。

官方支持在 CLI、IDE 扩展和 ChatGPT/Codex 桌面应用中使用 Skills。项目级 Skills 放在项目根目录的 .agents/skills 中。

第五步：第一次验证

在 Codex 中粘贴：

请不要修改任何文件。告诉我：
1. 你读取到了哪些 AGENTS.md；
2. 你发现了哪些项目 Skills；
3. 用5行以内总结当前工作规则。

能看到五个 Skill 名称，说明安装成功。

日常怎么使用

打开 prompts 文件夹，根据任务复制对应模板：

01-修改小功能.txt：增加小功能或修改页面
02-修复报错.txt：解决报错、502、Docker、Nginx、Cloudflare 等问题
03-只分析不修改.txt：担心 Codex 乱改时先分析
04-继续未完成项目.txt：继续上一次工作
05-检查本次修改.txt：提交前检查
06-让Codex填写项目资料.txt：第一次安装后使用

把方括号中的内容替换成你的实际需求即可。

Skill 如何手动调用

在支持 Skill 选择的界面中，可以使用 /skills 查看 Skills，或在提示词中输入 $ 后选择 Skill。

也可以直接复制：

`1`	`请使用 $project-navigation、$minimal-code-change 和 $targeted-testing。`

排查报错时复制：

`1`	`请使用 $diagnose-before-fixing。`

如果界面没有自动补全 $技能名称，直接用自然语言写出 Skill 名称也可以；Codex 也会根据 Skill 的 description 自动判断是否调用。

最省额度的使用习惯

一次只完成一个明确功能。
指定允许读取和允许修改的目录。
小修改不运行完整构建和全部测试。
长对话使用 /compact，不同功能使用新会话。
复杂任务先用 Plan 模式，确认方案后再修改。
不要同时启动多个 agent 处理同一问题。
不要安装大量重复 Skills；本工具包的五个已足够大多数小项目。
每完成一个阶段，让 Codex 更新 PROJECT_STATUS.md。
重要修改前先提交 Git，避免反复回滚。
普通任务优先使用较轻量模型，疑难问题再切换更强模型。

哪些内容需要你自己修改

AGENTS.md 是通用规则，通常不用改。

PROJECT_STATUS.md 建议填写：

项目要做什么
使用什么框架
当前完成到哪里
下一步是什么
哪些文件不能改

如果项目有特殊测试命令，也应写进去。

卸载方法

删除项目根目录中的以下内容即可：

.agents/
AGENTS.md
PROJECT_STATUS.md
prompts/

AI & Automation on 拾光集

How to Remove the AI Feel from Your Writing

Why AI-Generated Writing Often Feels Artificial

What to Look for Before Rewriting

1. Sentences That Are Too Perfectly Structured

2. Repeating the Same Point

3. Unnecessary Conclusions

4. Abstract Language

Remove “Correct but Useless” Sentences

Reduce Mechanical Transitions

Avoid Forced Parallel Structure

Do Not Over-Explain Obvious Points

Preserve Information Density

A Practical Two-Step Editing Method

Step 1: Identify What Should Change

Step 2: Rewrite the Text

A Prompt You Can Use

The Most Important Editing Rule

DeepSeek Harness 安装教程：让 DeepSeek V4 更稳定地接入 MCP、Claude Code 与 AI 编程工具

一、安装前准备

二、最推荐：通过 MCP 安装 DeepSeek Harness

三、安装命令行版本

四、Python 项目安装

五、Claude Code 安装 Skill

六、推荐搭配哪些插件？

1. Context7

2. Filesystem MCP

3. Playwright MCP

4. Git / GitHub

5. Sequential Thinking 类工具

七、我更推荐的组合

DeepSeek Harness 值不值得安装？

GitHub 项目

MiniMax H3 怎么本地部署？用 ComfyUI 搭建 AI 视频生成环境

MiniMax H3 主要解决什么问题？

可直接复制的部署提示词

为什么不能直接按显存下载？

四步 LoRA 加速要注意什么？

本地运行是不是只需要电费？

是否值得部署？

总结

参考资料

Agent-Reach：给 AI Agent 增加 Twitter、B站、小红书等联网能力

Agent-Reach 是什么？

它解决的主要问题

agent-reach doctor 检查配置

它并不等于“真正无限制访问全网”

1. 平台规则随时可能变化

2. 部分平台需要登录信息

3. “零 API 费用”不代表完全没有成本

Agent-Reach 适合谁？

是否值得安装？

总结

Headroom 是什么？给 Claude Code、Codex 压缩上下文减少 Token

Headroom 是怎么减少 Token 的？

到底能够省多少 Token？

压缩之后会不会影响回答？

哪些场景更适合 Headroom？

使用前需要知道的限制

总结

参考资料

Caveman Skill 是什么？让 Claude Code、Codex 少说废话并减少输出 Token

Caveman 能减少多少 Token？

它主要删掉哪些内容？

Caveman 怎么安装？

Windows

macOS / Linux / WSL

哪些场景适合使用？

哪些情况不适合？

Caveman 值不值得装？

总结

DeepSeek 怎么识别图片？用 Reasonix + GLM-4V-Flash 添加免费视觉能力

DeepSeek 识图是怎么实现的？

第一步：申请智谱 API Key

第二步：让 Reasonix 封装视觉 MCP

第三步：把 MCP 封装成 Skill

实际识别效果

为什么不直接换一个多模态模型？

使用前需要注意什么？

API Key 不要直接写入 Skill

`agent-reach doctor` 检查配置