最近在技术社区里DeepSeek Harness 的讨论热度上升得很快。它不是一个普通的 IDE 插件也不是又一个聊天客户端包装而是把“提示词工程”这件事带进了真正的工程化链路。很多人第一次看到它的目录结构、Preset、Skills 配置时第一反应是这难道不是把一套开发框架搬到了 LLM 应用上从实际体验来看这个方向是对的。过去我们用 LLM 做开发辅助最头疼的不是模型能力不够而是对话上下文不稳定、提示词无法复用、工具调用散落在各个聊天窗口里。同一个任务换个会话、换台机器、换个人效果就完全不一样。DeepSeek Harness 要解决的正是这个问题把模型参数、系统提示词、任务流程、工具插件全部固化成项目文件纳入版本管理让 LLM 驱动的开发任务变得可复现、可维护、可协作。这篇文章会从一个完整的实战项目切入使用 DeepSeek Harness 从零开发一个 LLM Wiki 知识库。整个开发过程拆成 11 个阶段从项目初始化、Preset 配置、Skills 编写、插件接入到最终的文档生成与效果验证全部走通。读完这篇文章你会理解 DeepSeek Harness 的核心概念、安装配置方式、以及如何用它构建一个真实的“AI 辅助开发”工作流。1. 这篇文章真正要解决的问题如果你只是偶尔用 LLM 写点文案、改段代码可能体会不到 Harness 的价值。但当你尝试用 LLM 完成一个稍微复杂的工程任务比如“构建一个持续更新的技术 Wiki”“做一个能自动查找资料并输出结构化文档的知识库”问题立刻就会出现。典型场景是这样的你在一个聊天窗口里花了 30 轮对话终于让模型生成了满意的项目结构。但新开一个会话所有上下文全部丢失只能从头再聊一遍。你总结了一套很有效的提示词模板但只能复制粘贴到备忘录里。换个同事来做他根本不知道你的提示词约定。你想让模型在写文章时自动搜索最新资料但不同的客户端工具调用搜索插件的方式完全不同没有统一标准。你希望不同文档保持统一的写作风格、结构和质量但每次都要在提示词里重复描述这些要求效率极低。DeepSeek Harness 的定位就是把这些散落在“对话”里的隐性知识变成项目里的显性文件。核心判断DeepSeek Harness 真正降低的是“提示词工程”的重复成本而不是模型本身的使用门槛。它用软件工程的方式管理 Prompt、工具和模型交互。Preset 固定了模型的角色、参数和上下文Skills 把某个领域的操作流程封装成可复用技能包插件则用来扩展 Harness 的工具能力。什么样的读者最应该读这篇文章正在用 LLM 做知识库、文档系统、内容生产工具的开发者和技术运营。团队里已经开始用 AI 辅助开发但提示词和流程无法沉淀、无法复用的技术负责人。对 Agent、LLM 应用开发有兴趣但还没找到一套清晰的工程化路径的进阶开发者。在开始动手之前先建立几个基本概念。这些概念不搞清楚后面看配置文件会非常吃力。2. DeepSeek Harness 的核心概念与 LLM Wiki 范式2.1 DeepSeek Harness 是什么DeepSeek Harness 是一套围绕 LLM 应用开发和智能体工作流的开源工具链。它的核心能力不是提供一个对话界面而是把“模型调用、提示词管理、工具插件、任务流程”整合到一个统一的命令行与配置体系中。你可以把它理解成“LLM 应用的工程化脚手架”。它提供了一套标准化的文件结构、配置规范和命令工具让你能够像写代码一样写提示词像管理依赖一样管理 Skills像安装 npm 包一样安装插件。2.2 LLM Wiki 范式Andrej Karpathy 提出的 LLM Wiki 范式在 DeepSeek Harness 的社区里经常被提及。它的核心思想是把知识沉淀的组织方式从“聊天记录”变成“Wiki”。什么是 Wiki 范式普通知识库文章写完之后就固定了更新靠人工编辑。LLM Wiki用 LLM 持续生成、校验、更新文档知识库本身是可生长的。Wiki 不只是存放文档的地方每一篇文档都可以关联到对应的 Skills、Preset 和插件形成一个“可执行的知识体系”。放到 DeepSeek Harness 里这个范式的具体表现就是你的文档生成规则写在 Preset 里。你的写作流程模板写在 Skills 里。你的知识来源通过插件获取。生成结果沉淀到 Wiki 目录并可以被后续任务再次引用。2.3 Preset、Skills、插件的区别这是 DeepSeek Harness 使用中最容易混淆的三个概念先看对比表概念作用类比典型文件Preset 预设固定模型参数、系统提示词、上下文范围代码项目里的环境配置文件.harness/presets/wiki-builder.yamlSkills 技能包封装特定任务的执行流程和提示词模板编程中的公共函数或工具库skills/wiki-writer/SKILL.md插件扩展 Harness 的工具能力如搜索、解析、执行代码npm 包、VSCode 插件.harness/plugins.yamlPreset 解决的是“模型以什么身份、什么参数、在什么上下文中工作”的问题。Skills 解决的是“某个任务应该按什么步骤执行、输出什么格式”的问题。插件解决的是“模型需要哪些外部工具才能完成任务”的问题。三个概念配合使用才能构建出一个完整的自动化工作流。只配置 Preset 而没有 Skills相当于模型有角色有参数但不知道完成任务的具体流程只有 Skills 而没有插件相当于有流程但缺少获取外部信息的能力。3. DeepSeek Harness 安装与前置条件DeepSeek Harness 对运行环境的要求并不高但它依赖 Node.js 和 pnpm安装前建议先把这两个环境确认好。3.1 环境准备需要准备的工具Node.js 18 或更高版本。pnpm 8 或更高版本。Git用于项目初始化和版本管理。一个终端工具macOS 和 Linux 用户直接用系统自带终端Windows 用户建议使用 PowerShell 或 Windows Terminal。检查环境的命令node -v pnpm -v git --version如果没有安装 pnpm可以通过 Node.js 自带的 npm 安装npm install -g pnpm3.2 安装 DeepSeek Harness确认环境无误后安装 DeepSeek Harnessnpm install -g deepseek/harness国内网络环境如果安装较慢或失败建议先切换 npm 镜像源npm config set registry https://registry.npmmirror.com然后重新执行安装命令。安装完成后验证dsh --version如果输出版本信息说明安装成功。3.3 初始化项目创建一个新的工作目录并初始化项目mkdir llm-wiki cd llm-wiki dsh init my-llm-wiki初始化命令会自动生成项目骨架目录包括.harness、skills、kb、wiki等基础目录。3.4 启动 Web 界面DeepSeek Harness 提供 Web 交互界面启动命令是dsh web启动后浏览器访问http://localhost:3000即可进入 Web 界面。安装过程中有一个高频问题值得提前说很多人在执行dsh web时发现界面一直卡住半天没有反应。从社区反馈看最常见的原因是首次启动时需要下载 Web 端依赖并完成资源打包加上部分网络环境下载慢看起来就像卡死了。这种情况建议先检查 pnpm 镜像配置然后耐心等待首次构建完成。如果超过几分钟仍然无响应再考虑端口占用问题可以换端口启动。到这里环境已经准备好了。接下来是本文最核心的部分11 个阶段从零开发 LLM Wiki 的完整流程设计。4. 从零开发 LLM Wiki11 阶段全流程设计构建一个可用的 LLM Wiki不是简单地让模型“写一篇文档”就行。它需要我们把整个过程拆成可验证、可回溯的阶段。标题里出现“10 轮提示完成工业级项目”这样的说法核心价值其实不在“轮次少”而在于通过 Preset 和 Skills 把原本需要反复对话引导的问题固定下来让每个阶段的目标、输入、输出都清晰可控。每一轮提示的上下文不再是空白而是带着前一个阶段的结构化产物继续推进。下表是完整的 11 个阶段设计阶段目标关键产物使用的 Harness 能力阶段 1项目初始化与 Wiki 骨架搭建项目目录结构、基础配置dsh init阶段 2定义领域模型与文档规范文档分类、标签体系、命名规范Preset 中的上下文定义阶段 3编写 Preset 基础配置模型参数、系统提示词、工作区Preset阶段 4设计核心提示词引言、正文、总结、引用等段落模板Preset Skills阶段 5构建 Skills 技能包写作流程、质量检查清单Skills阶段 6接入插件搜索、文档解析、代码运行能力插件阶段 7实现文档解析 Pipeline从原始材料提取结构化信息插件 Skills阶段 8实现知识检索基于 Wiki 已有内容生成新文档Web 搜索 本地知识库阶段 9文档生成与校验生成符合规范的 Markdown 文档dsh run阶段 10测试与迭代修复生成质量问题检查清单 人工 review阶段 11发布与沉淀将 Skills/Preset 提交到 Git版本管理这 11 个阶段符合一个基本原则先搭骨架再固定上下文然后建设技能最后跑通批量生成。下面按顺序深入拆解每个阶段的实操内容和关键配置文件。5. 阶段 1-3项目骨架、领域模型与 Preset 配置5.1 项目初始化与目录结构第一阶段执行dsh init my-llm-wiki后会得到类似这样的目录结构llm-wiki/ .harness/ presets/ plugins.yaml settings.yaml skills/ kb/ wiki/ scripts/ README.md各目录职责.harness/presets存放所有 Preset 配置文件。.harness/plugins.yaml声明项目使用的插件。.harness/settings.yamlHarness 全局设置。skills存放所有技能包。kb知识库原始材料目录。wiki生成的 Wiki 文档输出目录。scripts辅助脚本。5.2 定义领域模型领域模型决定 Wiki 的边界。LLM Wiki 不等于随便让模型写文章它应该有清晰的分类和标签体系。在这个实战项目里我们定义 Wiki 主题为“LLM 技术知识库”包含以下分类基础概念什么是大语言模型、Token、上下文窗口等。精度与训练FP16、FP32、BF16、混合精度训练等。推理与部署模型量化、推理加速、部署框架。应用开发Prompt 工程、Agent、RAG、Skill 编写。在.harness/settings.yaml中定义分类# 文件路径.harness/settings.yaml wiki: title: LLM 技术知识库 categories: - id: basics name: 基础概念 - id: precision name: 精度与训练 - id: inference name: 推理与部署 - id: application name: 应用开发 naming: pattern: {{category}}-{{slug}}.md example: precision-fp16-bf16.md这样定义的目的是让模型生成文档时明确知道自己该写什么主题、输出什么命名格式。5.3 Preset 配置详解Preset 是整个 LLM Wiki 工作流的“地基”。它负责固定模型身份、参数和上下文范围。创建第一个 Preset 文件# 文件路径.harness/presets/wiki-builder.yaml name: wiki-builder description: 用于构建和更新 LLM Wiki 文档 model: provider: deepseek name: deepseek-chat temperature: 0.3 max_tokens: 4096 context: system_prompt: | 你是一名资深技术文档工程师和 LLM 应用架构师。 你的任务是撰写结构清晰、内容准确、可落地的技术文档。 写作时遵循以下原则 1. 每个概念先给通俗解释再给技术定义。 2. 复杂内容必须使用对比表格或分步骤说明。 3. 涉及代码时必须提供完整可运行的示例。 4. 文档末尾必须列出参考资料。 workspace: ./wiki knowledge_base: ./kb tools: - web-search - file-reader字段说明model.provider模型提供商这里使用 DeepSeek。model.name模型名称这里使用deepseek-chat。model.temperature温度参数控制生成的随机性0.3 适合技术文档类任务。model.max_tokens生成文本的最大长度。context.system_prompt系统提示词固定模型的角色和写作规范。context.workspace生成文档的输出目录。context.knowledge_base本地知识库路径。tools允许模型使用的工具列表。Preset 配好后每次执行任务都不需要在对话里重新描述这些背景Harness 会自动加载。6. 阶段 4-5核心提示词设计与 Skills 技能包编写6.1 核心提示词不是一段话而是一套模板很多人理解“提示词工程”以为就是写一段很长的 Prompt。但在 DeepSeek Harness 的体系里提示词是被拆成多个模块的。按照文档结构拆分提示词模板例如一篇文章应该包含引言模板说明文章背景和读者收获。概念解释模板用通俗语言解释核心概念。对比分析模板用表格对比不同方案。示例代码模板给出完整代码和运行说明。总结模板提炼关键结论。每个模板都可以独立维护避免一大段提示词里混入过多要求导致模型执行混乱。6.2 Skills 的本质是“任务流程 提示词模板”Skills 是 DeepSeek Harness 中复用性最强的组件。它的本质是把某一类任务的可执行流程和提示词模板打包成一个标准目录结构供多个项目复用。举个实际例子。在“wiki-writer”这个 Skill 里我们不光要告诉模型“请写一篇文章”还要告诉它完整的工作流程理解任务主题。检索本地知识库和外部资料。列出文章大纲。分段生成内容。对照质量检查清单校验。输出最终文档。创建 Skill 目录结构skills/ wiki-writer/ SKILL.md prompts/ outline.md article.md checklist.md编写SKILL.md定义技能元信息和执行流程# 文件路径skills/wiki-writer/SKILL.md --- name: wiki-writer description: 用于撰写结构化 Wiki 技术文档 version: 1.0.0 tags: - documentation - wiki - llm --- # Wiki Writer Skill ## 适用场景 生成技术 Wiki 文档适合知识库建设、技术博客整理、团队文档沉淀。 ## 执行流程 1. **理解主题**使用 prompts/outline.md 生成文章大纲。 2. **资料收集**基于大纲检查 kb 目录中的本地资料必要时调用 web-search 插件补充外部信息。 3. **内容生成**使用 prompts/article.md 分段生成文章正文。 4. **质量检查**使用 prompts/checklist.md 逐项校验生成结果。 5. **输出**将最终文档保存到 wiki 目录命名遵循 {{category}}-{{slug}}.md 规范。prompts/article.md是正文生成的提示词模板# 文件路径skills/wiki-writer/prompts/article.md 请根据以下大纲生成一篇技术 Wiki 文档主题是{{topic}} 要求 1. 开头 200 字说明这篇文章解决什么问题目标读者是谁。 2. 每个概念先用一个生活化类比解释再给出技术定义。 3. 至少包含一个对比表格用于比较不同方案或参数。 4. 所有代码示例必须完整、可运行并标注文件路径。 5. 用“常见问题与排查方法”章节收尾使用表格列出问题、原因、解决方案。 6. 输出格式为 Markdown使用 ## 和 ### 作为标题层级。 大纲 {{outline}}这个模板的价值在于无论谁来执行这个任务用的都是同一套写作规范。团队里任何成员使用同一个 Skill 跑任务得到的文档结构就是一致的。7. 阶段 6插件机制与常用插件7.1 插件解决什么问题DeepSeek Harness 的插件机制和 VSCode 插件、Chrome 插件非常相似核心功能保持精简扩展能力通过插件按需加载。在 LLM Wiki 项目里如果没有插件模型的“知识”就只来自训练数据和本地文件。有了插件模型才能做到搜索互联网上的最新技术资料。解析 PDF、Word、Markdown 等不同格式的文档。执行本地代码并获取运行结果。调用外部 API 获取实时数据。7.2 项目里推荐启用的插件在本项目阶段 6 中先安装几个核心插件dsh plugin install web-search dsh plugin install doc-parser dsh plugin install code-runner安装完成后在.harness/plugins.yaml中统一管理# 文件路径.harness/plugins.yaml plugins: - name: web-search enabled: true options: max_results: 5 - name: doc-parser enabled: true options: max_file_size_mb: 20 - name: code-runner enabled: true options: allow_network: false timeout_seconds: 30插件配置说明web-search写作时自动检索互联网资料max_results控制单次搜索返回的结果数。doc-parser解析本地知识库中的 PDF、Word、Markdown 文件。code-runner在沙箱中执行生成的代码allow_network: false表示禁止代码访问网络提升安全性。社区里也有大量场景化插件比如前端开发 Skills 辅助包、文档解析增强插件、特定行业的“大国工匠”系列插件包等。这类插件通常是针对某个领域深度定制的一组 Skills 和工具集安装思路和通用插件一致建议大家按实际业务需求选择不要一次性全装。7.3 插件在任务执行中的工作方式插件不是独立运行的它会在任务执行过程中被自动调度。例如当 Wiki Writer 技能执行到“资料收集”流程时Harness 会判断当前上下文需要外部信息自动调用 web-search 插件并把搜索结果注入到模型上下文。这一切都发生在同一个工作流中不需要人工复制粘贴搜索结果。8. 阶段 7-9完整示例——生成 FP16/FP32/BF16 精度对比文档从这一节开始我们跑通一个完整的实战任务。示例需求是使用 DeepSeek Harness 生成一篇关于《LLM 大模型之精度问题详解FP16、FP32、BF16》的技术 Wiki 文档。8.1 项目结构确认在动手之前先确认项目结构完整llm-wiki/ .harness/ presets/ wiki-builder.yaml plugins.yaml settings.yaml skills/ wiki-writer/ SKILL.md prompts/ outline.md article.md checklist.md kb/ llm-basics.md wiki/ README.md scripts/8.2 准备本地知识库材料在kb目录下准备一份基础材料Harness 读取后作为生成的参考素材。# 文件路径kb/llm-basics.md ## 大语言模型的数值精度 大语言模型在训练和推理过程中通常使用低精度数值格式来减少内存占用和计算开销。 常见格式 - FP3232 位浮点数精度高占用内存大。 - FP1616 位浮点数训练速度快但数值范围有限容易溢出。 - BF16Brain Floating Point16 位浮点数与 FP32 有相同的指数位动态范围大适合深度学习训练。 混合精度训练在训练过程中同时使用 FP16 和 FP32梯度更新使用 FP32前向传播和反向传播使用 FP16以平衡速度和精度。 推理部署推理阶段可以使用 FP16、INT8、INT4 等量化格式进一步压缩模型体积提高推理速度。这份材料不需要非常完整它的作用是给模型提供基础上下文和正确的知识锚点。8.3 运行任务在项目根目录执行命令dsh run --preset wiki-builder --skill wiki-writer --task 生成一篇关于 FP16、FP32、BF16 精度对比的技术 Wiki 文档这个命令的含义--preset wiki-builder加载之前配置的 Preset固定模型角色、参数和上下文。--skill wiki-writer加载 Wiki Writer 技能包按照 SKILL.md 定义的流程执行。--task传入用户的具体任务指令。执行过程中Harness 会执行以下步骤读取 Preset 中的系统提示词和模型参数。加载 wiki-writer Skill。根据任务主题调用 outline.md 生成大纲。检查kb目录下的本地资料。调用 web-search 插件检索 FP16/FP32/BF16 相关资料。调用 article.md 模板生成正文。调用 checklist.md 执行质量检查。按命名规范保存到wiki目录。8.4 关键流程的提示词模板outline.md的模板内容# 文件路径skills/wiki-writer/prompts/outline.md 请为主题「{{topic}}」生成文章大纲。 大纲要求 1. 至少包含 5 个一级章节。 2. 必须包含章节背景介绍、核心概念对比、实践示例、常见问题。 3. 每个章节下用一句话说明该章节的核心内容。 4. 输出为 Markdown 列表格式。checklist.md的质量检查模板# 文件路径skills/wiki-writer/prompts/checklist.md 请对以下文档逐项检查并以表格形式输出检查结果 | 检查项 | 是否通过 | 说明 | | --- | --- | --- | | 是否包含对比表格 | 是/否 | 需要说明对比内容 | | 是否包含代码示例 | 是/否 | 需要说明示例是否可运行 | | 是否使用分级标题 | 是/否 | 需要检查标题层级是否超过 3 级 | | 是否包含常见问题章节 | 是/否 | 需要说明问题数量 | | 是否有本地知识库引用 | 是/否 | 需要说明引用了哪些资料 | | 是否有外部资料引用 | 是/否 | 需要说明是否使用 web-search |8.5 生成的文档预期效果运行完成后在wiki目录下会生成一个新文件文件名类似precision-fp16-bf16.md。文章预期包含大语言模型为什么需要低精度表示。FP16、FP32、BF16 的位宽、精度、动态范围对比表。训练阶段与推理阶段分别适合哪种精度。PyTorch 中的精度设置代码示例。混合精度训练的关键注意事项。常见问题与排查方法。9. 运行结果与效果验证任务执行完成后不能只看“生成了文件”就认为成功。技术文档的质量必须经过结构化验证。9.1 验证命令检查生成的文档是否落在正确目录ls -la wiki/预期输出中包含precision-fp16-bf16.md。9.2 质量检查脚本手动检查文档结构比较费时间可以写一个简单的 Python 脚本辅助检查。# 文件路径scripts/check_wiki_doc.py import re import sys from pathlib import Path def check_doc(filepath): content Path(filepath).read_text(encodingutf-8) filename Path(filepath).name issues [] # 检查标题 if not re.search(r^# , content, re.MULTILINE): issues.append(缺少一级标题) h2_count len(re.findall(r^## , content, re.MULTILINE)) if h2_count 4: issues.append(fH2 章节数量偏少: {h2_count}) # 检查表格 if | --- | not in content: issues.append(缺少 Markdown 表格) # 检查代码块 if not in content: issues.append(缺少代码块) # 检查参考资料 if 参考资料 not in content: issues.append(缺少参考资料章节) if issues: print(f[FAIL] {filename}) for issue in issues: print(f - {issue}) return False else: print(f[PASS] {filename}) return True if __name__ __main__: target sys.argv[1] if Path(target).is_dir(): files Path(target).glob(*.md) results [check_doc(f) for f in files] sys.exit(0 if all(results) else 1) else: sys.exit(0 if check_doc(target) else 1)运行脚本python scripts/check_wiki_doc.py wiki/如果输出[PASS] precision-fp16-bf16.md说明文档通过了基础结构检查。9.3 判断任务是否成功判断一个 LLM 任务是否成功可以按以下维度评估功能层面文件是否正确生成目录是否正确。结构层面文档标题层级、表格、代码块是否符合预设规范。内容层面是否准确解释 FP16/FP32/BF16是否有对比是否有实际代码。引用层面是否引用了本地知识库或外部检索到的资料。如果生成结果不达标第一步应该检查 Skills 里的提示词模板而不是质疑模型能力。大多数质量问题出在流程描述不够具体或者检查清单没有发挥作用。10. 常见问题与排查方法在实际使用 DeepSeek Harness 的过程中有几个高频问题需要特别注意。问题现象可能原因排查方式解决方案dsh命令找不到全局安装失败或 PATH 未配置执行npm root -g查看全局目录检查 PATH重新安装并配置 PATHdsh web卡住网络下载依赖慢、端口被占用检查 pnpm 镜像源使用lsof -i:3000查看端口切换镜像源、等待首次构建、更换端口启动安装依赖失败网络源问题查看安装日志确认是否卡在下载阶段执行npm config set registry https://registry.npmmirror.com后重装Preset 加载失败YAML 语法错误或文件路径不对检查文件缩进确认 Preset 文件名与命令一致使用dsh preset list查看已加载的 PresetSkills 未生效SKILL.md 格式不完整或目录命名不规范检查 SKILL.md 中的 frontmatter确认skills目录下每个 Skill 都有完整的SKILL.md生成内容质量不稳定温度参数过高或提示词模板描述不具体检查 Preset 中 temperature 配置将技术文档类任务的 temperature 设置为 0.2-0.4插件调用失败插件未启用或网络权限受限检查.harness/plugins.yaml中 enabled 状态确认插件安装成功并已启用生成的文档结构混乱提示词模板缺少结构要求检查 article.md 中的标题层级要求在模板中明确写出标题格式和章节顺序这里重点说一个经验很多初学者遇到“生成质量不行”时第一反应是换模型或者调 temperature但真正的根因往往是 Skills 里的检查清单没有执行到位。检查清单不是给模型看的装饰它是质量保障的最后一道关卡。如果任务生成了但不校验LLM 工作流就永远停留在“碰运气”阶段。11. 最佳实践与工程建议11.1 Preset 先固化再迭代不要在项目初期频繁修改 Preset。先把一套完整的配置固化下来跑通全流程再根据效果做小步迭代。Preset 的每次改动都会影响所有下游任务频繁改动无法判断质量变化来自哪里。11.2 Skills 按任务粒度拆分Skill 的设计原则是“小且专”。比如wiki-writer只负责写文档不要让它同时负责代码审查和数据分析。如果要新增一个任务类型就新建一个 Skill而不是往现有 Skill 里堆逻辑。11.3 插件按需启用插件不是越多越好。每个插件都会消耗模型的思考空间增加上下文的复杂度。一个 LLM Wiki 项目先启用 web-search、doc-parser、code-runner 三个基础插件就够了遇到具体需求再扩展。11.4 所有配置纳入版本管理.harness目录和skills目录应该提交到 Git 仓库。这样才能保证团队内所有成员用同一套 Preset 和 Skill 执行任务。建议添加wiki/生成的产物到 Git 时单独管理避免生成文件频繁变动干扰 review。11.5 先跑最小示例再跑批量任务在批量生成大量 Wiki 文档之前一定要先跑一个最小示例。用一篇文章跑通全流程确认质量之后再扩展成 10 篇、100 篇。不要第一次就批量跑否则一旦 Preset 配置有问题会浪费大量 token。11.6 安全边界这也是使用 LLM 工具链时最容易被忽略的问题不要在 Preset 和 Skills 中写入任何 API 密钥。启用 code-runner 插件时生产环境建议关闭网络权限。涉及外部数据源时确认授权和脱敏合规。敏感技术文档不应通过外部搜索插件获取资料避免信息泄露。11.7 团队协作时的命名规范团队多人协作时建议约定统一的命名规范Preset 命名{领域}-{用途}.yaml如wiki-builder、code-reviewer。Skill 命名{任务}-{场景}如wiki-writer、>