很多人以为 AI 写作助手就是把一段文字丢给大模型让它“扩写”或“润色”。这能应付一次性任务但离真正的“专属助手”还差很远。这次我们聊的是怎么用 Claude 把你的个人知识、笔记、收藏、经验整理成一套可持续输出的写作系统让 AI 在了解你知识背景的前提下按你的语气和结构要求生成内容。这套方法不需要本地 GPU不需要部署大模型核心就三件事知识整理、提示词工程、接口调用。这个项目/工作流最值得关注的点有这么几个一是用 Claude 的 Projects 功能做长期知识库让模型持续参考你的资料二是用自定义指令固定写作风格和输出结构三是用 API 把写作流程接进自己的工具链支持批量生成、定时任务和二次处理四是不挑显卡普通笔记本只要能联网就能跑五是可以从免费网页版一路延伸到付费 API按需选择。下面我会完整演示从知识库搭建到 API 调用的全过程包括可以直接复制的提示词模板、Python 请求代码和常见报错排查。适合的读者很明确有一定笔记积累、想稳定输出技术博客或行业内容的人以及想给团队搭一套统一写作规范的开发者。如果你只是偶尔让 AI 写一段文案这篇文章能帮你把“偶尔用”变成“系统用”。1. 核心能力速览先把这套方案的整体规格列出来方便你判断要不要继续看。能力项说明项目类型基于 Claude 的个人知识库写作工作流硬件要求无 GPU 要求能联网的电脑即可API 调用与本地算力无关主要功能知识库检索、写作风格控制、文章大纲生成、批量内容生产、API 集成知识来源Markdown 笔记、PDF、网页收藏、公众号文章、Obsidian / Notion 导出文件使用方式Claude.ai Projects / Claude API / 第三方客户端是否支持批量任务支持通过 API 脚本对多篇文章或多个主题批量生成是否支持接口 API支持Anthropic Messages API输出格式Markdown、纯文本可在提示词中指定结构适合场景技术博客写作、行业分析、公众号内容、内部知识沉淀使用边界生成内容需人工复核知识库文件需确认版权与隐私合规从这张表能看出这更像是一套“工作方法 工程配置”而不是一个需要安装的软件。它的门槛主要在提示词设计和知识库组织不在硬件。2. 适用场景与使用边界2.1 适合谁有大量笔记但不知道怎么转化成文章的人。比如 Obsidian 里存了几百条技术踩坑记录直接复制给 Claude让它按时间线或问题类别组织成文。需要稳定输出行业内容的新媒体运营。把历史文章、选题库、竞品资料交给 Claude它就能按你的风格起草新内容。需要统一团队写作规范的开发团队。把接口文档规范、代码风格指南、发布检查清单放进知识库Claude 生成的文档会自带约束。想批量处理内容的开发者。比如把几十个产品功能点批量生成对应的介绍段落或把会议纪要批量改写成周报。2.2 能解决什么问题“不知道从哪写起”Claude 根据你的笔记先出大纲你只需要确认方向。“写出来不像自己”通过自定义指令固定语气、句式、段落长度让输出贴近你的历史风格。“资料散落各处”用统一目录或标签整理知识库Claude 每次生成都会基于这些资料而不是凭空发挥。“重复性写作太耗时”API 脚本可以批量处理你只需要写一次提示词模板。2.3 不适合什么场景需要完全离线处理敏感数据。Claude 是云端服务你的文本会发送到 Anthropic 服务器涉密内容不要传。需要零幻觉的事实性内容。AI 仍然可能记错数字、编造引用涉及数据、法务、医学等严肃场景必须人工核对。需要训练专属模型。Claude 不是让你微调权重它只是在推理时参考你提供的上下文。如果你要训练自己的模型这套方案不适用。2.4 版权、隐私与安全边界使用 Claude 构建写作助手时有几点必须注意上传到知识库的文档请确认你有权使用。别人的付费课程、未授权转载的文章、内部保密文档不要传。生成内容的版权归属以你使用的服务条款为准。商用前先确认 Anthropic 的商用政策。涉及个人隐私的数据要脱敏。电话、地址、身份证号等字段先清洗再入库。如果知识库中包含客户信息或公司内部资料建议先咨询法务必要时改用企业版或私有化方案。3. 写作助手工作流设计在动手配置之前先明确整个工作流长什么样。个人知识库Markdown / PDF / 网页收藏 ↓ Claude Projects 或 API 上下文注入 ↓ 自定义指令 写作风格模板 ↓ 主题输入 ↓ Claude 生成大纲 → 草稿 → 修订稿 ↓ 人工审核 ↓ 发布 / 归档这套流程的核心不是“让 Claude 一次性写出完美文章”而是“让 Claude 在正确上下文约束下写出可用的初稿”。初稿质量越高你后续修改的成本越低。4. 环境准备与前置条件这一节不需要安装重型依赖但要做三件事注册账号、准备 API Key、整理知识库目录。4.1 账号准备访问 Anthropic 官网注册 Claude 账号。网页版有免费额度和付费订阅两种免费额度足够做功能验证。如果要长期使用或调用 API建议按官网说明开通付费套餐具体价格以官网为准。部分地区或网络环境可能无法直接访问需要自己评估网络条件本文不展开讨论。4.2 API Key 准备如果要走接口调用需要去 Anthropic Console 创建 API Key。# API Key 不要提交到 Git建议用环境变量保存 export ANTHROPIC_API_KEYsk-ant-xxxxxxxx创建 Key 时注意Key 只显示一次丢失后需要重新生成。给 Key 设置额度限制防止脚本失控产生高额费用。不要把 Key 写在前端代码里也不要截图发到群里。4.3 Python 环境如果要用 Python 脚本调用 API建议用虚拟环境。python -m venv claude-writer source claude-writer/bin/activate # Windows 用 claude-writer\Scripts\activate pip install requests4.4 知识库目录结构知识库整理是这套方案里最重要的一步直接决定输出质量。建议按主题分目录不要把所有文件堆在一起。knowledge-base/ ├── 01-tech-notes/ │ ├── docker踩坑记录.md │ ├── k8s网络排查.md │ └── python性能优化.md ├── 02-product-thinking/ │ ├── 产品经理的决策框架.md │ ├── 用户访谈方法.md │ └── 2024行业观察.md ├── 03-writing-style/ │ ├── 我的写作风格示例.md │ ├── 文章结构模板.md │ └── 禁用词表.md └── 04-raw-materials/ ├── 竞品分析资料.pdf └── 会议纪要汇总.md每个目录里放什么技术笔记你过去的踩坑记录、学习笔记、代码片段。写作风格示例你写得满意的一两篇文章让 Claude 模仿。禁用词表哪些表达你不喜欢直接列出来。原始素材零散资料先归档后续再清洗。关于文件格式Claude 的 Projects 功能支持上传 Markdown、TXT、PDF 等常见格式。文件不要太大单个文件建议控制在合理范围内过大的文档先拆分。5. 用 Claude Projects 搭建知识库如果你的使用场景是“网页版交互式写作”Claude Projects 是最直接的方式。5.1 创建 Project登录 Claude 网页版在项目区域新建一个 Project名称建议按领域命名例如“技术博客写作助手”“产品观察周报”“团队文档规范”。创建后Project 内部有两个关键配置项目知识库上传你的参考文档。自定义指令告诉 Claude 你的写作要求。这两个配置是分开的。知识库负责提供素材指令负责约束输出风格。5.2 上传知识库文件在 Project 的 Knowledge 区域上传之前整理好的文件。上传时注意每个文件要有清晰的名字比如“Docker踩坑记录-2024.md”不要用“新建文档 1.md”。如果一份文档太长先拆成多个小主题文件。文件上传后Claude 会自动纳入上下文参考。但 Project 的知识库不是无限上下文过于庞大的知识库会影响检索精度建议只保留高价值资料。5.3 编写自定义指令自定义指令是提高输出质量的关键。下面给一个可以直接改写的指令模板。你是一名资深内容编辑我的个人写作助手。请始终遵守以下规则 1. 写作风格 - 语言简洁先说结论再展开细节。 - 每段控制在 150 字以内段落之间逻辑清晰。 - 避免空话和套话不使用“综上所述”“随着技术发展”等表达。 - 技术类内容要给出可复现的命令或示例不写模糊描述。 2. 内容来源 - 优先参考我上传的知识库文件引用其中事实和案例。 - 如果知识库中没有相关信息明确说明“该内容需要补充资料”。 - 不要编造数据、引用和来源。 3. 输出结构 - 先给文章大纲等用户确认后再生成正文。 - 正文使用 Markdown 格式包含标题层级、代码块、表格。 - 长文控制在 2000 字左右也可以根据用户要求调整。 4. 修改要求 - 当用户要求修改时先说明修改思路再给出新版本。 - 保留用户认可的部分不要每次推倒重写。把这段指令粘贴到 Project 的 Custom Instructions 里以后每次对话都会生效。5.4 测试 Project 效果配置完成后可以直接在对话里测试。示例提问根据知识库里的 Docker 踩坑记录帮我写一篇技术博客主题是“Docker 容器启动失败的常见原因排查”。然后观察Claude 是否引用了你知识库里的具体案例。输出风格是否符合你的要求。大纲是否合理有没有遗漏关键点。如果输出不符合预期优先调整自定义指令而不是在每次对话里临时补充要求。指令写得越具体输出越稳定。6. 用 Claude API 接入自己的工具链网页版适合交互式写作但如果要做批量任务或者要把写作能力嵌入自己的系统就需要调用 API。6.1 通用 API 调用示例Anthropic Messages API 的调用格式是标准的 HTTP POST。下面用 Python 演示一个最小可运行示例。import requests API_KEY YOUR_API_KEY URL https://api.anthropic.com/v1/messages headers { x-api-key: API_KEY, anthropic-version: 2023-06-01, content-type: application/json } payload { model: claude-sonnet-4-20250514, max_tokens: 1024, system: 你是一名技术写作助手请用简洁、直接的语言输出 Markdown 格式文章。, messages: [ { role: user, content: 请写一篇 800 字的技术短文主题是 Python 虚拟环境的使用方法。要求先讲为什么需要虚拟环境再给出创建和激活命令最后总结常见坑。 } ] } response requests.post(URL, headersheaders, jsonpayload, timeout120) if response.status_code 200: data response.json() print(data[content][0][text]) else: print(请求失败:, response.status_code, response.text)注意几点model参数要以 Anthropic 官方文档实际提供的模型名为准不同时期的模型代号可能不同。system字段用来放全局指令适合写风格约束。messages数组里是对话历史每一轮都需要带上role和content。max_tokens控制生成长度文章较长时适当调大。6.2 用 curl 快速验证接口如果你只想验证 API Key 是否可用可以用 curl。curl https://api.anthropic.com/v1/messages \ -H x-api-key: YOUR_API_KEY \ -H anthropic-version: 2023-06-01 \ -H content-type: application/json \ -d { model: claude-sonnet-4-20250514, max_tokens: 256, messages: [ {role: user, content: 用一句话介绍 Claude API 的用途。} ] }如果返回 JSON 中包含content字段说明接口调用成功。6.3 把知识库注入 API 请求API 本身没有 Projects 那种文件上传界面需要你自己把知识库内容拼到请求里。常见做法是读取本地 Markdown 文件作为system或user消息内容。在system里写规则在user里贴素材和任务描述。示例def read_file(path): with open(path, r, encodingutf-8) as f: return f.read() knowledge read_file(knowledge-base/01-tech-notes/docker踩坑记录.md) task 根据以下笔记写一篇 Docker 排错文章。笔记内容\n\n knowledge payload { model: claude-sonnet-4-20250514, max_tokens: 1500, system: 你是一名技术写作助手。请基于用户提供的笔记内容写作不要编造笔记中没有的事实。, messages: [ {role: user, content: task} ] }这种方式适合知识库文件较少、单个文件内容不超长的场景。如果你的知识库非常大一次性塞进上下文会导致 token 消耗过高这时候需要做检索或切片只把相关片段注入请求。6.4 批量生成任务批量任务是 API 方案的主要优势。比如你有一个选题列表希望每个选题生成一篇初稿import requests import time topics [ Python 虚拟环境使用指南, Docker 容器日志查看技巧, Git 回滚操作的三种方式 ] API_KEY YOUR_API_KEY URL https://api.anthropic.com/v1/messages headers { x-api-key: API_KEY, anthropic-version: 2023-06-01, content-type: application/json } for topic in topics: payload { model: claude-sonnet-4-20250514, max_tokens: 1500, system: 你是一名技术写作助手请输出 Markdown 格式文章。, messages: [ {role: user, content: f请写一篇技术博客主题{topic}。要求800字左右包含实例和代码块。} ] } response requests.post(URL, headersheaders, jsonpayload, timeout120) if response.status_code 200: article response.json()[content][0][text] filename foutputs/{topic.replace( , _).replace(/, _)}.md with open(filename, w, encodingutf-8) as f: f.write(article) print(f已生成: {filename}) else: print(f生成失败: {topic}, 状态码 {response.status_code}) time.sleep(1) # 避免请求过于密集批量任务的关键建议每个任务独立写入文件避免一个失败影响其他任务。加上重试机制遇到 429 限流或 5xx 错误时等待后重试。任务数量多时建议把中间结果记录到日志文件方便排查。先跑 3 个测试任务确认输出格式稳定后再跑全量。7. 打造高质量写作提示词模板很多人在用 Claude 写作时觉得“生成的文字太泛”根本原因不是模型不行而是提示词没有约束。下面给出一套经过验证的提示词组织方法。7.1 模板结构一个完整的写作提示词包含四部分角色设定Claude 是谁。任务目标这次要写什么。输入素材知识库内容或参考材料。输出要求格式、长度、风格、约束。7.2 写作提示词示例你是一名拥有十年经验的技术博客作者擅长的领域是云原生和 DevOps。 请根据下面的素材写一篇技术博客。 素材 [这里粘贴你的笔记内容] 任务要求 1. 文章标题要具体不要用“XX指南”这种泛标题要有问题感。 2. 开头直接说明这篇文章解决什么问题。 3. 正文包含操作步骤和代码示例代码必须完整可复制。 4. 每个章节使用清晰的小标题。 5. 如果素材中没有提到的细节不要自行补充。 6. 全文控制在 1500 字左右用 Markdown 格式输出。把素材、任务、约束分开写Claude 更容易理解你的意图。7.3 风格模仿提示词如果你希望 Claude 模仿你的风格可以给它看一篇你满意的文章并明确要求模仿。下面是我写的一篇文章请分析我的写作风格然后按照同样的风格写一篇新文章。 我的文章 [粘贴文章内容] 需要分析的维度 - 段落长度 - 句子节奏 - 用词偏好 - 是否使用提问句式 - 小标题的组织方式 分析完成后请用这种风格写一篇主题为“XXX”的新文章。这种“先分析再写作”的两步流程比直接说“模仿我的风格”更有效。7.4 提示词迭代方法第一次生成的提示词往往不够好。改进思路是输出太泛就继续收紧约束比如“每段必须有具体例子”。输出太长就在指令里加上“正文控制在 1000 字以内”。输出没有个人风格就让 Claude 先分析风格范文再动笔。输出内容空泛就要求“结合知识库中的具体案例展开”。提示词不是一次写好的而是根据输出结果不断调整。建议把最终稳定的提示词保存下来作为模板复用。8. 从知识库到文章的完整实操演示下面演示一个完整流程从 Obsidian 笔记到一篇技术博客。8.1 准备素材假设知识库里有这样一段笔记2024-03-12 Docker 容器启动失败 现象容器启动后立刻退出docker logs 无输出。 排查过程 1. docker ps -a 查看容器状态显示 Exited (0) 2. docker logs 无日志输出 3. 检查 entrypoint发现脚本第一行有语法错误 4. 修正后重新构建镜像容器正常启动 原因entrypoint 脚本执行失败容器主进程退出导致容器退出。 经验容器启动失败时先看 exit code再看 entrypoint 和 CMD。8.2 写提示词在 Claude Projects 对话里输入请根据知识库中的 Docker 笔记写一篇技术博客。 主题容器启动后立刻退出的排查思路。 要求 1. 标题要具体体现出这是一个常见故障排查场景。 2. 结构按照“现象 → 排查过程 → 原因 → 解决方案 → 经验总结”组织。 3. 加入 docker ps -a、docker logs 等命令示例。 4. 内容控制在 800 字左右。8.3 预期输出理想情况下Claude 会输出一篇结构清晰的文章包含现象描述排查步骤命令示例原因分析预防建议如果输出没有用知识库里的具体案例而是泛泛而谈说明知识库文件的关联度不够或者指令里没有明确“必须引用知识库内容”。8.4 验证标准判断生成结果是否合格的几个标准是否引用了知识库中的具体笔记内容。命令是否完整能否直接复制执行。结论是否与笔记一致没有新增错误事实。结构是否符合要求的文章模板。9. 资源占用与性能观察这套方案是云端 API本地资源占用非常低不需要关注 GPU 显存重点观察的是 API 的响应时间、token 消耗和成本。9.1 响应时间影响响应时间的因素包括输入文本长度。知识库内容越长首次响应越慢。输出长度。max_tokens越大生成时间越长。模型版本。不同模型的速度有差异具体以实际测试为准。网络延迟。API 请求走公网网络波动会影响体验。建议在脚本里打印响应时间方便观察start time.time() response requests.post(URL, headersheaders, jsonpayload, timeout120) elapsed time.time() - start print(f请求耗时: {elapsed:.2f}s)9.2 Token 消耗Token 是 API 计费的基本单位。一篇文章的消耗主要来自输入部分知识库内容 提示词 对话历史。输出部分Claude 生成的正文。批量任务场景下token 消耗会快速累积。建议每次请求只注入最相关的知识片段不要全库灌入。对话历史没必要每次都完整携带可以只保留最近几轮。先小规模测试估算单篇成本后再跑批量。9.3 如何控制成本给 API Key 设置月度限额。在代码里记录每次请求的 token 使用量定期统计。对长文任务先让 Claude 输出大纲确认后再生成正文避免整篇重写。批量任务分批次执行每批结束后确认输出质量。10. 常见问题与排查方法下面列出使用 Claude 构建写作助手时最容易遇到的问题。问题现象可能原因排查方式解决方案API 返回 401API Key 错误或已失效检查请求头中的 x-api-key重新生成 Key确认没有多余空格API 返回 429请求超过速率限制查看响应头中的 retry-after增加请求间隔或降低并发数API 返回 400请求参数格式错误检查 model、messages 字段对照官方文档修改请求体生成内容与知识库无关指令没有要求引用知识库检查提示词是否包含“基于素材”在 system 指令中明确引用要求输出内容太长或太短max_tokens 设置不当查看实际输出长度调整 max_tokens 参数生成内容风格不像自己缺少风格范文提供一篇满意文章做参考使用风格模仿提示词批量任务中途失败网络波动或限流查看日志中的错误码增加重试和日志记录知识库内容过多导致响应慢注入上下文太长检查请求的输入 token 数先做检索只注入相关片段10.1 API 调用报错处理如果遇到claude: 无法将“claude”项识别为 cmdlet、函数、脚本文件或可运行程序的名称这类报错通常是因为你用了 Claude Code 的命令行工具但没安装或者命令名不对。本文使用的是 HTTP API 方式不依赖命令行工具。如果你确实需要命令行工具应该先安装 Anthropic 官方提供的 CLI再按官方文档初始化配置。不要尝试用第三方来路不明的安装脚本。10.2 网页版回答不理想网页版 Project 回答不理想时优先排查自定义指令是否写清楚。知识库文件是否真的被引用。提问是否太宽泛。比如问“帮我写篇文章”就很宽泛改成“根据知识库里的 XX 笔记写一篇主题为 XX 的技术博客要求包含命令示例”会好很多。10.3 批量任务卡住批量任务卡住常见原因是单个请求超时。建议在代码里设置合理的timeout并对失败任务做重试。for attempt in range(3): try: response requests.post(URL, headersheaders, jsonpayload, timeout120) response.raise_for_status() break except requests.exceptions.RequestException as e: print(f第 {attempt 1} 次请求失败: {e}) time.sleep(2) else: print(请求多次失败跳过该任务)11. 最佳实践与使用建议11.1 从最小可运行单元开始第一次搭建时不要追求“全自动”。先用 3 到 5 篇高质量笔记写成一篇测试文章确认风格和流程没问题再逐步扩大知识库。11.2 分目录管理素材建议项目管理采用四段式目录原始素材未经整理的收藏和笔记。清洗后素材去重、脱敏、格式化后的文件。写作风格参考你的历史高质量文章。输出文章Claude 生成的草稿和最终发布稿。这样每次跑批量任务都能知道哪份文件是输入、哪份是输出。11.3 批量任务要留痕任何批量任务都要记录日志。建议每一条任务记录输入文件、调用时间、输出文件、状态、错误信息。方便事后追溯。11.4 人工审核不可省AI 生成内容不能直接发布。重点检查技术细节是否准确。数字和引用是否有来源。是否泄露隐私或敏感信息。是否符合平台发布规范。11.5 定期更新知识库写作助手的效果依赖知识库的时效性。建议每两周清理一次过期内容补充最新笔记。不要让旧资料长期占据上下文干扰生成质量。12. 总结与下一步这套方案的最终价值是把分散的个人知识变成结构化的内容产出。最值得先验证的是自定义指令 知识库的配合效果拿你最有积累的一个领域整理 5 篇笔记让 Claude 生成一篇测试文章观察它是否准确引用了你的素材。最容易踩的坑有两个一是提示词太宽泛导致输出泛泛而谈二是知识库不整理文件过多、过杂、过大导致 Claude 无从参考。前者靠多轮迭代提示词解决后者靠分目录、拆文件、定期清理解决。后续可以继续扩展的方向包括把 API 接到飞书文档或 Notion 实现自动发布流程用检索机制对大规模知识库做切片只注入相关上下文把批量生成脚本改造成带定时任务的自动化管道把写作规范沉淀成团队共享的提示词模板。如果你也想搭一套“个人知识 → 稳定内容”的流程建议先收藏这篇文章按第 5 节的步骤在 Claude Projects 里跑通第一版。跑通之后再决定要不要继续接 API 做自动化。