引言：为什么菜单角标是独立站SEO利器

导航菜单作为网站架构的关键组件，在SEO（搜索引擎优化）中扮演着双重角色：帮助搜索引擎梳理页面层级，同时以视觉线索引导用户注意力，驱动点击与转化。本文分享一个简单实用的技巧——在导航菜单项右上角添加自定义颜色的文字角标，快速吸引访客目光。

外贸独立站和跨境电商网站的成功，很大程度上依赖于流量的有效获取。流量通常分为免费的自然流量（主要通过SEO实现）和付费流量（如搜索引擎广告、社交媒体推广、网红带货等）。对商家而言，尽可能扩大自然流量的占比、降低对付费渠道的依赖，是控制成本、提升长期竞争力的关键。下面这套SEO辅助方法，能让您的独立站菜单成为转化入口，充分释放自然流量的价值。

效果演示

实现效果：在网站主导航菜单的特定项目右上角，显示一个彩色文字角标，醒目突出，有效引导访客点击，提升页面触达率和转化率。

典型应用场景：
①为促销活动、限时优惠等专题页面在菜单中增设角标，吸引注意力；
②为热门商品集合、主推爆品等链接附上角标，增加曝光。

操作步骤

本方法适用于基于WordPress构建的独立站。

第一步： 进入主题根目录，找到 style.css 文件，在末尾粘贴以下 CSS 片段。

纯色示例代码

渐变色示例代码

您可以根据需求修改 CSS 中的颜色值，自由定制更多角标样式。

第二步： 在 WordPress 后台的「外观」→「菜单」中，找到需要添加角标的菜单项，在导航标签字段输入以下 HTML 代码：

<span class="n-mark-red">必看 </span>

其中 n-mark-red 是第一步中 CSS 定义的类名，您可以替换成其他自定义类名，如 n-mark-blue、n-mark-gradient 等。

完成以上设置后，醒目的角标便会显示在菜单里，成为引导自然流量的有效触点。

不妨回忆一下，当你试图用语言向别人描述一段音乐时，对方往往只能无奈地说：“有点像 Billie Eilish，但更轻柔，还有一段钢琴……算了，你还是直接听吧。”在这个瞬间，语言放弃了解释，转而邀请对方直接体验。这并非语言的无能，而是提醒我们：语言本质上是对经验的有损压缩。就像任何压缩形式一样，它总会舍弃一些东西——音色、质感、空间布局，或某种难以言表的整体氛围。

在人工智能近几十年的发展历程中，我们一直把这种“压缩”视为理所当然。搜索与检索系统普遍遵循一个隐含的前提：如果一件事没有被文字记录下来，它就不存在。

你有一档播客？先转录成文字。
你有一份扫描版 PDF 报告？用 OCR 提取文本。
你有一张战略会议上白板的照片？那就麻烦了。

每一次转换，都伴随着“损耗成本”——一点失真，一点信息的流失，让原始内容变得不那么完整。

可如果不再强迫一切数据都必须转化为文字，而是直接在原始形态下处理，却仍然能够搜索、比对和推理呢？

这正是多模态嵌入所赋予的能力。它将文本、图像、音频和视频映射到同一个嵌入空间，使得源于任意一种模态的查询，都能从其他所有模态中检索出相关结果。本文将深入探讨其工作原理，解释为何最新一代模型让其变得真正实用，并通过三个当下就可以构建的真实系统案例，展示如何把多模态嵌入与大语言模型结合起来，打造可落地的应用。

嵌入：理解向量空间的语义本质

在深入多模态之前，有必要先明确“嵌入”到底是什么。

嵌入是一种对输入数据（文本、图像、音频或任何信息）的学习型表示，被编码成高维数学空间中的一个点。例如，像 text-embedding-3-large 或 nomic-embed-text 这样的模型，接收一个句子作为输入，会返回一个通常包含数千个维度的向量。

嵌入最关键的特性在于：语义相近的输入，在嵌入空间中彼此靠近。比如，“dog”和“puppy”的向量距离很近，而“jira 工单”与“派对策划”的向量则相距甚远。

这正是现代检索系统的基石。不同于传统的关键词匹配，现在我们比较的是向量：将整个文档库编码为向量，再将查询语句编码为向量，然后检索出嵌入空间中最邻近的向量。最终实现的是语义搜索——它理解的是内容的含义，而非仅仅匹配字面词汇。

文本嵌入在这一任务上已表现出色多年。但顾名思义，它的局限也很明显：它只理解文本。如果你的数据是其他形式（如音频、图像或视频），就必须先转换为文字，否则就完全无法利用。而正如前文所述，这种转换有代价——信息会丢失。

共享嵌入空间：跨越模态的统一表示

想象一位技术支持工程师正在搜索公司的知识库，而这个知识库不仅包含文本文档，还有客户通话录音、扫描版技术手册和产品演示视频。他输入查询：“阀门密封件在压力下失效的那个部分”。答案其实就在一段 40 分钟的故障排查视频中，大约第 22 分钟处，屏幕上清晰展示了失效过程。

在纯文本嵌入的检索流程中，这种情况几乎无解：

• 即便将视频中的语音转录为文字，也只能捕捉到“说了什么”，却无法反映“画面中展示了什么”；
• 对技术手册做 OCR，图示信息会丢失；
• 视频字幕（如果有的话）通常只记录对话，不会描述操作人员的手部动作或设备状态。

信息明明就在知识库里，却因为格式问题变得“不可达”。

从概念上讲，解决办法其实很简单：把所有模态的数据都编码到同一个共享的嵌入空间中。这样一来，不论查询是文本、图像还是音频，都能跨模态匹配到最相关的内容。

真正的挑战在于：如何训练出一个模型，能稳定、一致地在不同模态之间实现这种对齐。这需要海量的多模态数据、精心设计的训练目标以及强大的模型架构——而近年来的技术进步，正让这一目标变得愈发可行。

模型如何学会对齐不同模态：对比学习的魔力

实现多模态对齐的核心技术是对比学习。其思路很直接：收集成对的多模态数据——比如一张照片及其对应的标题、一段音频与它的文字描述——然后同时训练两个编码器，一个处理图像，一个处理文本。

训练信号非常直观：

• 配对的数据（如图片与它的真实标题）在嵌入空间中应彼此靠近；
• 未配对的数据（如图片与随机标题）则应彼此远离。

在每个训练批次中，模型会将每张图像与该批次中所有文本进行匹配打分，目标是让正确的图文配对获得最高相似度，而其他错误的配对则被惩罚。通过在数亿甚至数十亿这样的配对数据上反复训练，两个编码器最终会收敛到一个语义主导、格式无关的共享几何空间——在这个空间里，“狗”的图像向量和“狗”这个词的文本向量靠得很近，而与“汽车”或“交响乐”则相距甚远。

CLIP（对比语言-图像预训练，OpenAI，2021）是首个在大规模上成功验证这一方法的模型。它在4 亿个图像-文本对上进行训练，能够在零样本设置下准确匹配图像与文本，性能甚至可以媲美在特定任务上专门训练的有监督模型。

CLIP 的突破不仅在于规模，更在于它证明了：无需人工标注类别标签，仅通过自然语言描述与图像的弱对齐，就能学习到强大的跨模态语义表示。这为后续涵盖音频、视频等更多模态的嵌入系统奠定了根基。

继 CLIP 之后，ImageBind（Meta，2023）将对比学习扩展到六种模态：图像/视频、文本、音频、深度图、热成像和惯性测量单元（IMU）数据。更巧妙的是，它不需要所有模态之间都存在直接的配对数据——所有模态都通过图像作为“锚点”进行对齐，音频与文本等其他模态之间的关系会通过图像间接传递，形成一种“传递性对齐”。

然而，这种“桥接式”对齐隐藏着一个根本性问题。NeurIPS 2022 的论文《Mind the Gap》指出：每个模态的编码器在高维空间中会天然形成狭窄的锥形簇，而不同模态的锥形簇并不完全重叠。对比学习只关注配对样本之间的相对距离，并不会强制缩小模态锥之间的绝对间隙，因此模型没有动力去弥合这一鸿沟。这种分离会不可预测地影响检索精度，并在下游任务中引入偏差。

这一发现为下一代模型指明了方向：从零开始联合训练所有模态，采用单一统一架构。如今的原生多模态嵌入模型正是这么做的——它们不再依赖文本作为中介，而是让所有模态在同一个表示空间中协同学习。正是这种转变，使得下文将要讨论的应用从“理论可能”变成了“工程可行”。

设计多模态检索系统的关键决策

在具体实现之前，以下几项架构选择对实际效果的影响，往往比模型本身的选型更大。

原生嵌入 vs. 桥接式嵌入

• 桥接式（常见做法）：将所有数据先转为文本（如语音转录、OCR、视频字幕），再用成熟的文本嵌入模型处理。
  • 优点：简单，与现有系统兼容。
  • 缺点：承受全部“转换成本”——丢失音调、布局、视觉动作等关键信息。
• 原生嵌入（如 Gemini Embedding 2）：使用从头联合训练的多模态模型，直接以原始格式嵌入各模态。
  • 优点：保留音频中的语气、PDF 中的排版、视频中的操作动作。
  • 缺点：相对较新，工程生态仍在成熟过程中。

建议：若任务高度依赖于非文本语义（如故障诊断、艺术分析），优先考虑原生多模态嵌入。

随着Agent Harness范式的快速升温，香港大学数据科学研究所（HKUDS）全新开源的AI项目OpenHarness仅上线不到一周，便迅速积累起6.9k个GitHub Star，引发开发者社区的广泛关注。

项目地址：https://github.com/HKUDS/OpenHarness

OpenHarness（简称 oh）是 Agent Harness 模式的一个开源Python实现——它并非简单的“又一款AI聊天机器人”，而是大语言模型（LLM）外部的一整套基础设施层，能够将LLM转变为功能齐全的自主编程Agent。OpenHarness赋予了LLM 双手、双眼、记忆与安全边界，使其能够读写你的代码库、执行Shell命令、管理文件，并与其他Agent协作——所有行为都在可配置的治理规则下安全运行。

整个项目由163个文件中约11,700行Python代码构建，却实现了对Claude Code高达98%的工具覆盖（43个工具对比Claude Code约44个）以及61%的命令覆盖（54条命令对比约88条），而代码体积轻量了44倍。通过剥离遥测、OAuth复杂度等企业级负担，OpenHarness留下了一个纯净且对研究友好的Harness架构，任何人都能轻松理解、实验和扩展。

架构概览

OpenHarness以 10个子系统 为核心进行组织，每个子系统都封装在 src/openharness/ 目录下的独立包中。整体采用分层设计：Agent循环构成核心引擎，底层工具与技能为其注入能力，外围的治理机制保障安全，而UI层则暴露给人类用户进行交互。

OpenHarness 的五大支柱

Agent 循环 — 交互的心跳

Agent循环是驱动每一次交互的核心周期。它将当前对话（消息 + 可用工具）发送给LLM，并接收流式响应；一旦模型决定调用某个工具，循环就会执行该工具（经过权限检查与Hook），并将结果反馈回对话——如此重复，直到模型给出最终答案。循环运行在 QueryEngine 内部，由它管理对话历史、跟踪Token用量并掌控整个流程。

核心能力包括流式工具调用循环、并行工具执行、带指数退避的API重试以及实时的Token计数与成本追踪。

Harness 工具箱 — 43 款工具

工具系统建立在简洁的抽象之上：每个工具都继承自 BaseTool，提供用于类型安全校验的Pydantic输入模型，并返回标准化的 ToolResult。ToolRegistry 负责注册流程，并自动将所有工具转换为与API兼容的JSON Schema。

每个工具都自动融合了权限系统与Hook生命周期——无需任何额外配置。

学会对AI的道歉“免疫”

使用AI工具时，很多人都经历过这样的场景：你认真指出某个错误，AI也诚恳道歉，并承诺“我已经记住了”。你以为问题就此解决，但紧接着换一个对话窗口，同样的错误卷土重来；甚至就在同一个窗口里，隔一两天又重演了。

其实这并不奇怪。当前大部分AI并不具备真正的长期记忆能力。每一次新对话都意味着新的“智能体”，之前的上下文会被全部清空；即使在同一会话中，缓存也可能被清除，过去发生的事也就被“遗忘”了。所以，道歉更像是一种即时的话术回应，并不能真正改变未来的行为。

过去我也曾被这种“态度”打动，觉得AI说“你说得对”“我理解了”“以后会注意”时，它就已经吸收了教训。可反复三番之后才发现，它最大的特长就是“态度极好”——你骂它不生气，你纠错它立刻认，你让重写它二话不说。可惜，这种“听话”只在当下。如果你没有把犯过的错固定成某种永久记忆，下一次它很可能又踩进同一个坑。

所以，我们需要转变思路：别再把精力花在希望AI“长记性”上，而是想办法让它“再也没机会犯错”。AI归根结底是工具，工具需要持续调校，才能越来越懂得你的工作习惯。实现的方法主要有两个——把错误记成规则，或者封装成Skill。

方法一：将常见错误固化为规则

最近Github上很火的一份文档，本质上就是在做这件事：把AI高频错误整理成一条条规则。

这份文档源自Andrej Karpathy对日常使用AI时出现问题的吐槽汇总，核心原则可以概括为——“不假设、不臆测、不擅自改动、必须验证结果”。道理简单而通用，但放到你自己的场景里，仍然会遇到大牛也覆盖不了的细节。这时候，就需要你亲手把那些只属于你的“坑”写成规则。

举个例子，如果你频繁让AI创作文章，可以准备这样一组约束：

写文章时遵守以下规则：
1. 不用宏大背景开场，必须从具体场景切入。
2. 不在结尾硬套“三点总结”。
3. 绝不编造用户没有给出的个人经历。
4. 不要为了“完整感”把每段都写成说明书。
5. 如果不知道用户真实经历，用“这里可以补一个自己的例子”提醒，而不是替用户虚构。

再比如，我曾让AI检索关于Codex的资料，它明明可以直接参考项目文件夹里已有的完整教程，却偏要去互联网上漫无目的地搜索，不仅浪费时间还消耗大量 token。为了解决这个问题，我只需在项目的 AGENTS.md 里加一句规则：“查询 Codex 相关内容时，优先检索当前项目文件夹下的文档。” 就这一行，它从此再没犯过同样的错。

规则的优势在于：短小、明确，一句话就能堵死一条岔路。只要它适用于清晰的“不要做什么”的场景，规则就是最轻量的纠偏手段。

方法二：用Skill封装复杂流程

什么样的错误适合做成Skill？当无法用一两句话说清，或者必须按一整套固定流程执行时，规则就不够用了。你需要把一个完整的工作流封装起来，作为Skill固化。

比方说你让AI用Figma画图。如果只是随口下达命令，没有指定流程，AI很可能上手就画，看似积极实则无效——它没先理解需求、没拆解页面结构、没确定设计规范，也不知道哪些内容应该放主页面，哪些该弹窗或浮层。你这次费劲指导它改过来了，可下次再换一个任务，它又重走老路。

这时，一个Figma设计专用的Skill就能派上大用场，例如：

当用户要求用Figma画图时，严格按照以下流程执行：
1. 先理解要画什么，有任何不明确的地方先提问。
2. 拆分页面结构，梳理大板块、小板块及组件。
3. 输出设计方案，等用户确认后再继续。
4. 确认后才进入Figma开始执行。
5. 所有大板块用 Frame，小组件用 Group。
6. 弹窗、抽屉等浮层单独置于页面，不覆盖主页。
7. 完成时检查是否有重叠、错位或层级混乱。

这样一来，AI每次碰到Figma绘图任务时，就会自动按这条稳固的工作流运行，而不是临场发挥、到处乱撞。Skill的实质，就是把你自己验证过的正确路径强行锁定成 AI 的行为模板。

再举一个知识库整理的例子。之前我分享过《最近很火的用LLM搭建知识库的保姆级教程》，如果你仅仅在 CLAUDE.md 或 AGENTS.md 里写几条规则，很难实现理想的命名规范或个性化设置，这时候就需要补上一个专用的Skill。

规则和Skill互相配合后，整理知识库的过程会变得顺畅而稳定，AI再也不会在关键环节脱轨。

规则 vs Skill：如何选择？

判断标准其实很直观。能用一两句话说清楚、并足以杜绝错误的，就直接写成规则，例如“不要用某些词语”“不要硬总结”“不要编造经历”。如果涉及的是一整套容易出错的流程，比如写文章、整理知识库、做产品方案、画Figma、检查文稿等，就必须借助Skill来锁定整个链条。有些复杂项目甚至需要两者同时配齐，AI才会真正稳定下来。

需要提醒的是，现在AI圈流行一个词叫“Skillify”，主张把每一次AI的错误解决方法都赶尽做绝地做成Skill。我只认同一半。并非所有错误都值得上升为Skill，不加区分地堆砌Skill，不仅会加大token消耗，还可能让AI的表现越来越迟钝。在没成为资深玩家之前，不妨先试试这套规则+Skill的组合思维，好好琢磨一下怎么调教你的AI，效果会更扎实。

最近在X平台上看到一个名为awesome-design-md的GitHub项目被频繁推荐。

截至今天，它已累积超过32k Star，如此高的热度显然说明它有些过人之处。

起初我并未特别在意。毕竟这类资源层出不穷——提示词合集、设计资源库、灵感收集站，常常是收藏时满怀热情，转眼便抛在脑后。

但今日抽空试用之后，才发现这个项目确实内涵丰富，值得深入探索。

如果你也常使用Claude Code、Codex、Cursor这类AI代理编写前端，一定能理解接下来的内容。

现在用AI生成一个页面已非难事，结构、组件、按钮和卡片都能迅速搭建。

核心问题不在于能否生成，而在于生成的结果往往带有鲜明的“AI味”：渐变紫、emoji、发光卡片、千篇一律的排版，初见尚可，再看便觉腻烦。

其实，并非模型不会编写页面，而是缺少一套明确的设计约束。你给出了需求、代码上下文甚至AGENTS.md，但并未告诉它页面应该长什么样。模型只能基于训练数据中最常见的模式，输出一个“平均值”。当设计停在平均值上，平庸便难以避免。

awesome-design-md的巧妙之处正在于此：它将诸多知名产品的视觉语言系统化整理为AI可直接读取的DESIGN.md文件。它既不是组件库，也非灵感收集站，更像一份为AI代理量身定制的设计规范。将其放入项目根目录之后，AI在生成页面时便不再凭空猜测，而是能够明确遵循颜色范围、留白大小、圆角、阴影、字体和排版等视觉边界。

这一点至关重要，因为页面的高级感往往就取决于这样一层约束。

两套设计风格对比

泛谈概念未免空洞，因此我做了一个小实验。在完全相同的页面需求、同一AI代理、同一套任务描述和提示词下，尽量控制变量，唯一的不同就是<font style="background-color:#FBDE28;">DESIGN.md</font>。

模型使用Kimi官方的kimi2.5，工具通过Claude Code调用，共测试两组风格（详细提示词见文末）。

• 一组选用Claude风格。
• 一组选用Vercel风格。

之所以对比这两者，是因为它们的视觉差异十分明显。

Claude风格更显温和，布局舒展，贴近内容型产品，浏览时带来一丝陪伴感。

Vercel风格则完全相反：更冷、更克制，自带工程师气质，黑白灰对比强烈，留白充裕，充满秩序感。

生成结果展示

先看Claude风格的生成效果。

再看Vercel风格。

两个版本均是一次生成，未做任何手动调整。

两者风格迥异。个人更偏爱Vercel这套，干净利落，商业感更强；Claude版本也不错，更柔软，适合内容产品。你更喜欢哪一版？欢迎在评论区分享你的看法🤔。

DESIGN.md使用指南

仓库地址：https://github.com/VoltAgent/awesome-design-md

第一步，进入仓库，选择你想要对标的网站风格。

第二步，点击详情页，查看对应的设计说明与预览图，通常会提供明亮和暗色两种模式。

第三步，下载对应的图标及DESIGN.md文件。

第四步，将DESIGN.md放入项目根目录。文件名不必强制统一，但提示词中需明确指定其路径或名称。

第五步，把下方提示词提供给Claude Code、Codex、Cursor等代理，即可直接运行。

提示词如下：

你现在是一个资深前端架构师+ SaaS 产品设计师。  
  
请基于项目根目录的DESIGN.md 设计规范，生成一个完整的 SaaS 官网首页。  
  
产品名称：KkltCodePilot  
定位：AI编程助手（类似 Copilot，但更轻量、更智能）  
  
---  
  
## 🎯 目标  
  
构建一个“可用于演示+ 接近真实商业 SaaS 官网”的高质量页面，而不仅是简单静态页面。  
  
---  
  
## 🧱 技术要求  
  
-使用 React（函数组件 + Hooks）  
-使用 TailwindCSS（严格遵守 DESIGN.md 的设计系统）  
-组件化拆分（Header / Hero / Features / Pricing 等）  
-响应式设计（移动端优先）  
-代码结构清晰，便于扩展  
-不使用多余依赖（保持轻量）  
  
---  
  
## 🎨 设计风格  
  
-极简（Minimal）  
-现代（Modern SaaS）  
-科技感（Tech / AI 风格）  
-类似：Vercel / Linear / Stripe 风格  
-使用 DESIGN.md 中的：  
-色板（color tokens）  
-字体规范  
-间距系统  
-圆角 & 阴影规范  
  
---  
  
## 📄 页面结构（必须包含 + 可增强）  
  
### 1. Header（新增）  
-Logo（KkltCodePilot）  
-导航：Features / Pricing / Docs / GitHub  
-CTA：Start Free  
  
---  
  
### 2. Hero  
-标题：Ship code 10x faster with AI  
-副标题：Generate, fix and optimize code instantly  
-按钮：  
-Primary：Start Free  
-Secondary：View Demo  
-可增强：  
-右侧代码生成动画 UI（mock）  
-渐变背景 or glow 效果  
  
---  
  
### 3. Features  
必须包含：  
-AI 自动生成代码  
-一键修复 Bug  
-多语言支持  
-GitHub 集成  
  
优化：  
-使用卡片布局（grid）  
-每个 feature 包含：  
-icon  
-title  
-description  
-可增加 hover 动效  
  
---  
  
### 4. Social Proof  
-文案：10,000+ developers using CodePilot  
-可增强：  
-用户头像墙  
-Logo（GitHub / Vercel 风格）  
-评分（⭐️⭐️⭐️⭐️⭐️）  
  
---  
  
### 5. Demo Section（新增，提升 SaaS 感）  
-模拟 AI 编程输入输出界面  
-示例：  
-输入：“写一个快速排序”  
-输出代码块（带高亮）  
-让页面更“产品化”  
  
---  
  
### 6. Pricing  
套餐：  
-Free  
-Pro（推荐）  
-Team  
  
每个包含：  
-价格  
-功能列表  
-CTA 按钮  
  
增强：  
-高亮 Pro  
-Toggle（月付 / 年付）  
  
---  
  
### 7. FAQ  
-4~6 个常见问题  
-使用 Accordion（可展开）  
  
---  
  
### 8. Footer  
-产品信息  
-GitHub 链接  
-Docs  
-联系方式  
-Copyright  
  
---  
  
## ⚡ 交互增强（重要）  
  
适当增加这些能力，让Demo 更像真实 SaaS：  
  
-Hover 动效（卡片 / 按钮）  
-平滑滚动  
-按钮点击反馈  
-Pricing toggle（状态切换）  
-FAQ 折叠动画  
  
---  
  
## 🧩 组件结构建议  
  
请按以下结构拆分：  
  
-components/  
-Header.tsx  
-Hero.tsx  
-Features.tsx  
-Demo.tsx  
-SocialProof.tsx  
-Pricing.tsx  
-FAQ.tsx  
-Footer.tsx  
  
-pages/  
-Home.tsx  
  
---  
  
## 🧪 代码要求  
  
-使用语义化命名  
-Tailwind class 简洁清晰  
-不要写死颜色（优先使用 DESIGN.md token）  
-代码可直接运行  
  
---  
  
## 🎁 输出要求  
  
-输出完整 React 页面代码（可运行）  
-包含所有组件  
-不要解释，只输出代码

使用建议与注意事项

尽管优势明显，但也需要理性看待。这类样式约束特别适合新项目，比如落地页、产品官网、活动页或Side Project，以及需要快速探索多种视觉方向的情境。

近来许多人都在尝试搭建个人知识库，我也投入了不少时间。最初的理论指引来自 Karpathy 所倡导的 LLM 维基方法，但真正走完一圈后，最深刻的感触是：本地知识库的建设成本实在太高，仅仅 token 的消耗就足以让你反复心疼。

先从 Karpathy 的维基方法说起。我在另一篇文章里也详细拆解了这个方案的完整步骤，并按照同样的流程一步步实践。

我在知识库中集成了 19 个信息源，单单是把它们编译成维基就耗去了将近 20 分钟。随后我向它提了 10 个问题，查了一下，每个问题平均消耗约 44,000 个 token，10 个问题累计就是 44 万 token。额度几乎瞬间击穿。

这还仅仅基于 19 个来源。如果扩展到 50 个，仅编译阶段就足以让人头疼。况且现在的 token 价格并不友好，免费额度也在持续收紧。回想今年一月份，国内各大平台的 token 还几乎属于不限量供应，如今早已失去了那样的优待，就连 coding plan 都一票难求。

更要紧的是，哪怕付出如此高昂的成本搭建出一个维基，它和你的日常工作始终是脱节的。你可以向它提问，但仅此而已。问完即止，它不会反过来帮你做决策，更不会优化你的工作方法。

知识的静态存储，和将知识内化为己用，有着本质的区别。

基于此，我随后就停下了本地维基的探索。

后来，有人推荐了 NotebookLM。导入 50 个信息源的确眨眼之间就能完成，原因是它采用嵌入模型来做索引，并不需要大模型逐字阅读每个文件。同样针对 10 个问题，每个回答大概一分钟，且都能回溯到具体的引用出处。

NotebookLM 固然出色，可在国内使用总要多绕几个弯。我马上想到，国内市场会不会有相似的替代品？搜寻一圈后，真被我发现了。

它就是 ima，而且不出所料，出自腾讯之手。在借鉴与跟进这件事上，腾讯确实很有自己的风格。

ima 的官网为：https://ima.qq.com/，打开后界面非常简洁，扑面而来的是强烈的 NotebookLM 视觉风格。

我当下就迫不及待地想上手一试，结果发现，上传资料需要使用电脑版，需要先完成下载。嗯，这果然很腾讯。为了验证实际效果，我还是把客户端装好了。

随后，我把最近两周收集到的好东西一一放了进去，包含链接、图片和文档，总计 40 份左右，然后开始等待解析。

大概 5 到 10 分钟后，全部内容解析完毕。接着我再次测试了那 10 个问题。

ima 会从多个来源里将相关信息拼接整合出来，每个回答末尾都清晰标记了出自哪个文件、哪一页，体验和我在 NotebookLM 上的感受几乎一致。更关键的是，提问时还可以搭配 GLM 5.1 模型，并不限制使用次数，放在国内市场这已经是相当有诚意的配置了。

今天本来打算写一篇“如何直接用AI工具修改方案文档”的操作指南，但在整理素材的过程中，却意外形成了一个更让我想表达的观点——国产模型，确实更懂国人。

下面我就把得出这个看法的过程记录下来，同时也会分享一些用AI操作Word的踩坑经历。

作为一名普通上班族，我日常工作的一部分就是不断调整、润色各种方案，几乎每一天都要跟Word打交道。自然，当AI助手兴起后，我第一时间就想着让它替我分担这部分工作。刚好手上有个任务，于是干脆边干活边把过程整理成文。

我原先以为，让AI帮忙改Word会非常简单：把文档内容直接粘贴到对话框里，告诉它要改动哪些部分，然后它就能一键搞定。但真正上手才发现，现实远远不是我想的那样。

先拿Codex结合GPT-5.5来试。我按照上面的想法直接贴入Word内容，结果运行了半个多小时，连第一张表格的渲染都没过完，反复卡在那里。渐渐地我失去了耐心，索性让它先跳过表格，心想我自己手动调整总可以吧。然而它又困在Word标题和字体的渲染上，又是半小时过去了。

最终它吐出一大串脚本和代码，打开之后我大吃一惊——满篇都是一级标题的Word文档，吓了我一跳。

5小时的使用额度眼看就要耗尽，也快到下班时间了。

情急之下，我只好让它先输出Markdown文档，然后自己手动复制粘贴到Word里。总算勉强完成了任务。

用AI直接修改Word，本质上就是打通了办公流程的“最后一公里”。我用元宝、豆包这类国产工具，按提示词生成合适的文本完全没问题，但如果一个AI工具不能把内容直接、准确地写进Word，那这些文本能力在实际工作中就失去了大半意义。

于是我又拿Workbuddy加上GLM 5.1的组合尝试了一遍，因为之前总觉得Codex在调用skill时存在问题，也可能是自己刚接触，对它还不够信任。

我给Workbuddy的提示词是这样的：

“把md里面这个里面的内容写入到test.doc 这个word的4.数据资源治理。替换这部分内容。要求标题字体都要和原文档的标题和字体都内容保持一致。数据资源治理 对应word里面4.数据资源治理这一层级的标题。明白我的意思了吗？明白就开始工作吧”

执行过程中它也在写代码，也提示我这个Word文件版本较老，但整个流程看起来相当靠谱。

大约10分钟后，结果就呈现出来了。

说实话，我非常满意。除了三级标题没有沿用原来的序号样式，其他所有内容都准确无误地复刻到了文档里。反观Codex的表现，还不及Workbuddy。

首先是耗时，Workbuddy完成同一个任务前后只用了大约十分钟，而Codex执行一次就要半小时。其次是过程体验，Codex几乎每一步都会附带大段原因分析和后续计划，一旦执行不理想就开始“碎碎念”，说自己失败是因为哪些限制，接下来打算怎么做……就像职场上那种老实又积极但能力有限的同事，把事办砸后不停地解释。我这种急性子看着实在来气。

Workbuddy则完全不同，执行过程直接展示逻辑，不废话，或者说只给正向反馈，几乎不传递负面情绪，用起来让人心里舒服很多。这一点也正好印证了我说的——国产模型还是懂国人。

除了“耗时长、负反馈多”，Codex最大的问题还在于贵，使用几次就超出限额，而且额度有限。如果它能跟Workbuddy一样平价，那我一句怨言都不会有。但它的月费是国产产品的3倍，效果却一般，这等于在浪费我的预算，那它还有存在的必要吗？如果我是老板，或许会想：“不如把Codex裁掉，换两个Workbuddy给我干活算了。”

当然，有人可能会说用Codex来写文档是“大材小用”，它本身就不是为这种任务设计的，它的强项是搞定更复杂的程序与逻辑。这点我不否认，确实不该用简单的工作去刁难一位“海归高材生”，之后我也会给它安排更艰巨的任务，希望它到时候别再让我失望。

之前看过一个观点：顶尖的大模型为什么连“我应该开车去洗车还是走路去”这类问题都回答不好，那是因为它们并不在意这些低价值问题，这些不能给它们带来更高的经济回报。同理，一些写作、编辑Word文档的能力，也可能在某些模型的发展方向上逐渐被弱化，它们正全力向编程等更高阶领域高歌猛进。

理解了这条技术路线，我们就没必要总盯着所谓“最强的模型”不放，国产模型同样能满足日常需求。很多基础工作，比如处理Word文档这类任务，国产工具不仅能干，而且干得更好。

归根结底还是我标题那个观点：国产模型在训练和优化过程中，更贴近国人的使用习惯，因此才更懂我们的需求。以后在工作中，我们也要多给国产模型一些机会，让同一个团队里的每个“员工”都能发挥自己的特长，这才是我这个当“领导”的应该做的事。

前不久与一位深圳的电商朋友深谈，他透露业务重心已逐渐转向海外，团队自行搭建了独立站，并招揽了专业的跨境运营人才，坦言国内电商几乎走不通了。从今年618大促开始，大部分从业者都感同身受：国内赛道内卷到极致，不花钱就没有流量，一砸钱却又直接亏损。越来越多停步不前的国内卖家，毅然将目光投向跨境赛道，奔向广阔的外贸天地。

国家政策：跨境电商的硬核底气

2024年11月22日国务院政策例行吹风会上，商务部国际贸易谈判代表兼副部长王受文着重指出，跨境电商是国际贸易体系中不可忽视的新生力量，它能够精准满足个性化的消费需求，交货周期短，并对终端消费者具有明显的降本优势。在回应部分国家调整跨境小包裹免税政策带来的新考验时，王受文副部长态度鲜明地强调，这些阶段性挑战并不会真正动摇跨境电商的根本竞争力，因为其核心竞争力仍然稳固地掌握在我们手中。

四大举措，为跨境电商插上引擎

1. 强化供需对接：积极组织外贸企业与境外智慧物流平台进行资源默契，高频举办跨境电商交易博览会及专题供需对接会，直接为企业拓宽合作通道。
2. 系统性合规保障：面向超过12万家跨境电商出口企业输出专业培训，全面提升合规经营水平，精准化解报关流程、税务处理、产品质量把控、知识产权保护等环节的堵点。
3. 全速推进跨境电商赋能产业带：鼓励平台企业和链主企业与地方特色优势产业带深度融合，助力中小微企业平台上线，直接触达海外采购商，稳稳抓住线上订单。
4. 深化国际合作棋盘：借助双边自由贸易协定及世贸组织电子商务相关协定谈判，持续为跨境电商营造透明、稳定的国际发展氛围。

跨境电商独立站：你的全球商业新主场

乘着政策的暖风，跨境电商独立站正释放出空前的可能性。独立站让你能绕开中间环节，与海外消费者建立起直连的信任关系，并令品牌在全球市场中塑造出难以复制的辨识度。如今，全方位的政策支持已成我们披荆斩棘的坚实依托，令跨境电商独立站事业如虎添翼。抓住这阵东风，我们将并肩步入全球贸易的深水区，让每一个独立站都化作向世界输出中国好货的闪亮窗口。

这不是一个孤立的 Skill，而是一套紧密配合的小说创作技能组。

借助这套技能组，我已经完成了两部长篇小说和三部短篇小说。这些作品不仅顺利通过了平台的内容审核，读下来也能明显感受到，它们已经具备了相当不错的文学水准。后来出于个人时间原因，我没能继续创作下去，但还是本着开源分享的精神，今天决定把这套工具和思路公之于众。

缘起：当写作梦想遇上 AI 能力短板

我一直热爱写作，但文笔始终是我的软肋。脑海中各种奇思妙想翻涌不息，可一旦坐到屏幕前，往往半天也憋不出几个字，下笔如同干涸的河床。AI 的出现真正改变了这一切，让我得以把脑袋里的故事变成文字，所以我一头扎进去，开始反复打磨和炼化自己的写作 Skill。

五大技能协同的设计思路

这套小说创作技能组一共包含五个模块，它们分别是：小说大纲调研工具（novel-outline-researcher）、小说写作核心工具（novel-studio）、小说问题检查工具（novel-qa）、小说风格制作工具（novel-style-reference）和个人风格工具（yunhui-style-writer）。五个工具各司其职，又相互配合，形成完整的创作管线。

novel-outline-researcher（大纲调研工具）
主要负责帮助开题和理清思路，它会通过不断提问来引导我把脑中的模糊想法具象化、结构化。遇到卡文或者需要把整个大纲推倒重来的时候，这个工具也同样管用，能快速整理出新的方向。

novel-studio（写作核心工具）
这是整个体系的发动机。它可以按照我的意图依次输出大纲、人物小传、时间线，甚至详细的空间布置方案，然后再依据这些设定逐章完成小说正文。在写作过程中，我为它设计了大量关于文风自然度的规则和铁律，并要求它在写作中不断进行自我学习。经过多轮迭代，这个 Skill 已经能够相对独立地承担起主体叙事任务了。

novel-qa（问题检查工具）
专门用来诊断小说中的各种“硬伤”，比如前后情节矛盾、场景描写不一致、时间线错乱、人设前后崩塌，以及行文中的“AI 味”太重等问题，最后会生成一份结构化的质检报告，方便逐条修改。

novel-style-reference（风格制作工具）
这个工具的作用是通过阅读一些代表性作品，总结出特定作者的写作风格，然后在你创作时将这种风格迁移到你的文字中。我用它提取过村上春树、川端康成以及王家卫式的表达特征，也可以直接针对某一部小说进行风格提炼，让 AI 学会该作品的语气和节奏。

yunhui-style-writer（个人风格工具）
这一模块则专注于提炼和固化我自己的写作偏好，让输出更贴近个人的表达习惯，相当于把自己的“文气”教给 AI。

以上五个 Skill 分工协作，再配上我作为创作者的总体把控，便能一部接一部地生产出结构完整、语言流畅的小说。

还是要多提醒一句：即使是我打磨了很久的 novel-studio，在文风自然度方面虽然已经做了大量约束，但面对一些复杂的大纲内容，它有时仍然会把握不好，写着写着就飘了。如果反复调整也调不回来，最直接的办法就是停下 AI，换自己动手写。

三步走实操流程

整个写作过程大致可以分为三步：第一步，脑中构思；第二步，生成并敲定大纲；第三步，逐章写作完善篇章。

第一步：脑中构建故事雏形
你要先在脑海里搭好故事的框架，大致想清楚要写什么类型、什么题材，是长篇还是短篇，男女主的基本人设等等。这个阶段完全是在头脑和简记中完成，不需要任何工具介入。

第二步：用工具夯实大纲
当脑子里有了初步方向后，就启动 novel-outline-researcher，它会针对你的想法不断提问、补充细节，最终生成一份详细的故事构思报告。拿到这份报告后，再交给 novel-studio，这个核心工具会依据报告内容依次创建出作品的元信息（meta）、完整大纲（outline）、时间线（timeline）、人物小传（characters）以及重要场景（spaces）等。

大纲的生成并不是一次到位，它会先划分出故事有几幕，每一幕承载什么情节，然后才往前推进出前五章的详细大纲。这时候你需要反复审阅，用自然语言告诉 AI 哪里需要怎么改，一直调整到自己完全满意为止。如果怎么调整都觉得不对味，也可以直接把你自己手写的大纲内容粘贴进去，让 AI 在此基础上去续写。我自己到了小说中后期，基本上都是手写大纲，再让 AI 生成正文，因为越往后，纯靠 AI 构思的大纲确实有些乏力，不太能撑起故事。

第三步：逐章写作与打磨
大纲定型后，就可以开始正式的章节写作。你可以在大纲里就设定好每章的字数范围，但最好保证大纲的内容密度能匹配设定的字数，不然就会出现“为了凑字数而写”的状况，这一点我自己就深刻体会过。每写完一部分，我建议一定要自己出声或者默读一遍，如果连创作者自己都不愿意读完，就更别指望读者会有耐心。读完之后，再反复和 AI 商量怎么修改，直到你真正觉得“这就是我要的东西”。这样一来，最终呈现的作品是你自己的判断力和审美筛选出来的，而不是甩手全交给 AI 的结果。同时，novel-studio 也会结合上下文学习你对哪些用词和表达的不满，从而在下一章写作时主动规避，越来越贴合你的标准。

章节完成后，novel-studio 本身会进行一次自检。你也可以调用 novel-qa 进行更系统的核查，不过我个人用得比较少，因为我每一章都会自己认真细读。如果你习惯把重活都交给 AI，那这几个工具倒正好可以组成一条自动检查与修复的链路。

开源与你的创作自由

以上就是整套小说写作 Skill 组的建设逻辑和使用方法。相关的 Skill 文件已经全部上传到 GitHub，地址是：https://github.com/zhengyunhui123-dev/cursor-claude.git ，有需要的朋友可以直接获取。

开源并不意味着完全免费！在日常开发中，我们常常会借助开源软件和源码来提升效率。然而，为了规避潜在的商业风险，我们必须深入了解第三方软件的使用条款，包括其协议类型、版本以及已知的CVE安全漏洞等信息。本文将从开源软件再发布时的权限角度出发，系统梳理各类常见开源许可证的异同，帮助您快速建立起清晰的认知。

绝大多数开发者都乐于将自己的作品公开分享，让更多人查阅和使用。这不仅能够提升个人在业界的影响力，也能为需要的人提供帮助，践行开源精神。然而，一旦将代码公开，任何人都可以任意查看和获取，后续的使用行为便完全脱离了作者的控制。

因此，若想在分享代码的同时保留对代码的某些控制权，在项目中明确声明一份许可协议就显得至关重要。附带协议的代码与没有协议的“裸代码”存在本质区别。通常情况下，未声明协议的作品默认适用版权法（Copyright），即保留所有权利。这意味着他人未获得任何授权，不能进行复制、分发、修改或使用。一旦明确了许可声明，未来在维护自身权益时将更有据可依，让你在开放分享的同时，仍能守住部分权利。

许可证（License）就是软件的权利说明书，其中详细规定了使用者获得代码后所拥有的权限，明确界定了可以对他人作品进行的操作以及被禁止的行为。

从性质上，软件协议可分为商业协议与开源协议两大类别。

• 商业协议：也称为法律声明或许可协议，通常由软件作者或专业律师精心撰写。由于涉及到未来可能发生的侵权诉讼等法律问题，这类条款的措辞极为严谨考究，因此读起来往往晦涩难懂。
• 开源协议：需要明确的是，开源既不代表免费，也不代表毫无约束。虽然相较于商业协议，开源协议的条款更加简明扼要，但对不少初次接触者而言，理解起来仍像在翻阅“天书”。

主流开源协议概览

目前业界最主流的六种开源许可证分别是 GPL、BSD、MIT、Mozilla（MPL）、Apache 和 LGPL。乌克兰程序员 Paul Bagwell 绘制了一张清晰的选择分析图，帮助开发者快速理清它们之间的核心差异。以下是阮一峰翻译的中文版：

一、Apache 许可证：永久、无国界的权利授予

Apache 许可证（Apache License）是由 Apache 软件基金会发布的一款自由软件许可证，最初专为 Apache HTTP 服务器项目撰写。该许可证要求被授权者保留版权和免责声明，但它本身并非反版权的许可证。

目前最新的版本是 2004 年 1 月推出的“2.0 版”。Apache 许可证在 Apache 社区内外均得到了广泛应用：Apache 基金会旗下的所有项目均采用此许可证，此外，许多非 Apache 项目也选择了它。据统计，截至 2008 年 4 月，SourceForge 上已有超过 3000 个项目使用 Apache 许可证。

Apache 2.0 版为用户赋予了非常广泛的权利，这些权利不仅适用于著作版权，还覆盖了专利权。由于许多许可证仅能约束版权，而对专利权无能为力，这一灵活性为拥有专利的开发者提供了重要的选择依据。

Apache 许可证赋予的主要权利包括：

• 权利永久有效：一旦获得授权，这些权利便永久存在，不会失效。
• 无地域限制：在一个国家获得的授权，效力等同于在所有国家获得授权。例如，即使授权最初在印度签发，你在美国同样可以使用该程序。
• 无需付费：在使用前无需支付任何费用，使用过程中也无需支付任何形式的报酬。
• 非排他性：使用该许可证下的软件，并不妨碍你使用其他软件。
• 权利不可撤销：权利一经授予便不能剥夺。也就是说，你无需担心在自己基于该授权软件开发出优秀的衍生产品后，突然被禁止继续使用原程序。（协议中存在一个例外条款：如果你对许可协议下的产品提起专利权侵权诉讼，你的授权将自动终止。但这仅涉及专利作品，只要你不发起相关诉讼，就永远无需担心。）
• 再分发时的署名要求：对于再分发的作品，Apache 协议特别要求必须给予原始程序的作者和许可证的维护者适当的署名与致谢。

二、MIT 许可证：最简短、最宽松的协议

MIT 协议可以说是最流行、最短小精悍的开源许可证之一。其条款极其宽松，与其他协议相比自由度最高，被广泛认为是对使用者限制最少的协议。

基本上，只要认可该协议，任何人都可以对 MIT 协议下的软件做任何事情。协议中最重要的声明（即不提供担保的声明）位于结尾段落：

特此授权，任何人可免费获取本软件及相关文档的副本，并无限制地使用本软件，包括无限制的权利去使用、复制、修改、合并、发布、附加从属协议，以及/或销售软件副本。为了保证软件提供者能够授予这些权利，必须遵守以下条件：

上述版权声明和许可声明必须包含在本软件的所有副本和重要分发部分中。

这实际上意味着：

• 你可以自由使用、复制、修改该软件。没有人能阻止你在任何项目中使用它，你可以无限次复制、以任意形式传播，或按你的意愿进行修改。
• 你可以免费分发，也可以用于商业销售。分发行为没有任何限制。
• 唯一的约束就是必须接受协议条款。

三、BSD 许可证：自由与署名的平衡

BSD 协议拥有多个变种，但它们共同代表了一种宽松的自由软件许可模式。与 GPL 之类的协议相比，BSD 对软件再传播的限制要少得多。