最近我把日常的笔记整理、工作日报、架构图这几件高频又琐碎的事情全部交给一套免费开源的模板去处理了。你没看错不需要买会员不需要复杂的在线平台也不需要掌握多深的编程知识。一套基于 Markdown 的模板库配合本地运行的开源 AI 模型再加上文本转图表的开源方案就能把“记录”和“整理”之间的重复劳动全部压缩掉。这套模板我现在每天都在用适合经常写文档、做项目复盘、被迫画图的开发者和产品同学。这篇就把模板的完整结构、核心用法和踩坑记录一次性讲清楚。1. 项目定位与整体设计思路1.1 这三件事本质上是同一类问题笔记管理、写日志、生成架构图听起来跨了好几个领域但从信息处理的角度看它们其实是同一类问题把零散、无序的输入转化为结构化的输出。比如你白天开了一堆会随手记了七八条零碎想法晚上要写日报时你得回忆、归纳、组织语言把散乱的记录变成有条理的条目。再比如画架构图你脑子里其实已经有了系统的模块划分和调用关系但打开画图软件一个个拖框、连线时间就悄悄没了。AI 真正能帮上忙的不是替你思考而是替你完成“从零到粗略结构”这一步。模板要做的就是把这类“从零到一”的劳动统一接管过来。所以我设计这套模板时没有做一堆花哨的功能而是把三件高频任务收敛成同一条流水线一个输入口Markdown 草稿一条处理管道本地开源模型三个输出端分类笔记、格式化日志、Mermaid 架构图代码。这样一套逻辑解决多个问题维护成本也很低。1.2 为什么选 Markdown Ollama Mermaid方案选型的时候我对比过很多搭配最后锁定了三个核心组件Markdown、Ollama、Mermaid。说实话这个组合不是最“炫”的但它是把免费、开源、可控这三点平衡得最好的。首先是Markdown。它是纯文本格式任何电脑上都能打开任何脚本都能处理丢进 Git 里可以做版本管理以后想迁移到别的工具也毫无负担。相比绑定在某个云笔记里的私有格式Markdown 是真正属于你自己的数据。其次是Ollama这是一个本地运行大模型的工具安装简单命令行就能操作模型跑在本机数据不用上传也不用按字数付费。最后是Mermaid它用文本描述图表和 Markdown 天然互补写几行代码就能生成流程图、时序图、架构图渲染效果也够用。我为什么不选 Notion AI、在线笔记自带的 AI 功能理由很简单贵、数据上传、不方便批量处理。对于经常要处理几十篇笔记的人来说在网页里一篇篇点击处理是灾难。本地脚本一次性处理完体验天差地别。1.3 这套模板最适合谁根据我这段时间的使用经验下面几类人用这套模板收益最大每天写日报、周报、项目总结的职场人把下班前写日报的时间从 20 分钟压缩到 3 分钟。需要整理大量会议记录、读书笔记的知识工作者让 AI 自动提炼重点、打标签再也不用面对一堆原始文档发愁。经常画架构图但嫌工具繁琐的技术人员用自然语言描述系统组成AI 直接生成架构图代码导入文档就能渲染。想入门“AI 工作流”但不知道从哪下手的人这套模板就是一个可以抄作业的样例改改提示词就能适配自己的场景。2. 模板库设计与核心原理拆解2.1 目录结构一览这套模板开源在 GitHub 上仓库名我直接叫ai-workflow-template。克隆下来之后目录结构长这样ai-workflow-template/ ├── templates/ # 各类 Markdown 模板 │ ├── notes/ # 笔记类模板 │ │ ├── 日常笔记模板.md │ │ ├── 读书笔记模板.md │ │ └── 会议记录模板.md │ ├── journals/ # 日志类模板 │ │ ├── 每日工作日志模板.md │ │ ├── 周报汇总模板.md │ │ └── 项目复盘模板.md │ └── diagrams/ # 图表类模板 │ ├── 系统架构图模板.md │ ├── 业务流程图模板.md │ └── 时序图模板.md ├── scripts/ # 核心处理脚本 │ ├── ai_notes.py │ ├── ai_journal.py │ └── ai_diagram.py ├── config/ │ ├── model_config.yaml # 模型参数配置 │ └── prompts/ # 提示词与输入输出说明 │ ├── 笔记整理.txt │ ├── 日志生成.txt │ └── 架构图生成.txt └── README.md这个结构乍看之下有点“散”但我刻意把模板文件、处理脚本、提示词分成三个独立区域。这样设计有一个直接好处不懂代码的人只改 templates 和 config不碰 scripts懂代码的人可以自由调整处理逻辑不影响模板使用。人和代码之间通过文件格式解耦协作起来非常舒服。2.2 核心设计提示词与脚本分离这是整套模板里我认为最值得借鉴的设计。写 prompt 和处理逻辑混在一起是最常见的反面教材——一旦想调整 AI 的语气或者输出格式就得去翻代码改完之后还可能影响原有功能。我的做法是所有提示词全部放在 config/prompts 目录下脚本只负责三件事读取输入文件、拼接提示词和内容、调用模型并写回结果。这样调整 AI 行为时只需要打开纯文本文件改几行字不用理代码逻辑。举个例子config/prompts/架构图生成.txt 里存的是你是一位资深软件架构师。请根据用户描述生成 Mermaid 架构图代码。 用户描述如下 {input_text} 要求 1. 只输出 Mermaid 代码不要包含任何解释或前后缀。 2. 代码放在 markdown 的 mermaid 代码块内。 3. 节点命名要清晰关系描述要准确。脚本读取这个文本文件把{input_text}替换成用户的实际描述再发给模型。以后想换英文输出、想调整图表的风格改文本文件就行。这个“配置与代码分离”的思路放到任何工具里都适用。2.3 数据流向一条完整的处理链路整套模板的运行逻辑不复杂你可以把它理解成一个“输入-加工-输出”的管道。以笔记整理为例核心链路是你按照模板格式把零散想法写进一个 Markdown 草稿文件。脚本读取草稿把内容嵌入提示词模板拼接出完整的请求。请求发送给 Ollama 本地模型模型按提示词要求输出结构化结果。脚本解析模型输出把结果写入目标文件比如自动归类到对应目录并在终端打印摘要。整个过程串起来就是一条命令的事。日志生成和架构图生成也是一样的逻辑区别只在于提示词内容和输出文件的处理方式。数据在本地闭环流动不上传任何第三方服务这也是我敢把工作日志放心交给它的原因。3. 笔记、日志、架构图三大模板拆解3.1 笔记管理模板从“收集箱”到“分类库”先看笔记场景。我之前最大的痛点不是没记录而是记完就“石沉大海”——写了十几篇零散笔记回头根本找不到更别说归类整理了。日常笔记模板长这样--- 创建时间: 2025-01-08 22:10 标签: [待整理] --- # 关于新项目的一些想法 今天讨论了新项目的几个要点 - 用户端要用小程序管理端用 Web - 数据库预计需要支持千万级数据量 - 部署环境考虑容器化 另外还想到一个竞品分析的角度可以从用户留存的漏斗切入。运行python scripts/ai_notes.py drafts/新项目想法.md之后模型会返回--- 创建时间: 2025-01-08 22:10 标签: [项目规划, 产品设计, 技术选型] 建议目录: 工作/项目/新项目 --- # 关于新项目的一些想法 ## 核心要点 - 用户端采用小程序管理端采用 Web 架构 - 数据库需支持千万级数据量涉及容量规划 - 部署环境采用容器化方案 ## 延伸思考 - 竞品分析可尝试从用户留存漏斗切入关注转化率与流失节点这里有个我特别想强调的设计AI 给的是“建议目录”而不是直接把文件挪走。因为自动分类偶尔会出错一旦 AI 判断失误把文件移到错误目录你可能很久都发现不了。而输出“建议目录”你只需要手动按路径保存主动权始终在自己手里。实际操作中我还会在模板里增加一个“行动项”区块专门提取笔记中的待办事项。这样每篇笔记整理完顺手就能把要做的事情复制到任务清单里效果非常好。3.2 工作日志模板从“流水账”到结构化日报每天下班前写日报是很多人的噩梦。我的体验是白天干活的时候根本不会想着“这句话要写进日报”到了晚上回忆起来全是模糊的更别提还要按“完成事项、未完成事项、明日计划”的格式组织语言。模板的思路是不要让 AI 凭空生成日志而是让它加工你的原始流水账。你只需要在手机备忘录或草稿箱里随手记几行比如上午改支付模块的 bug搞了半天发现是回调参数大小写问题 下午跟产品对需求确认了优惠券叠加规则 晚上要上线有点慌运行python scripts/ai_journal.py drafts/今日流水账.md --date 2025-01-08模板对应的提示词会将其整理为# 2025-01-08 工作日志 ## 今日完成 - 修复支付模块回调参数大小写导致的 bug定位耗时较长已补充日志便于后续排查 - 与产品确认优惠券叠加规则明确“满减与折扣可叠加特价商品除外”的约束 ## 待跟进 - 今晚版本上线关注支付链路监控 ## 明日计划 - 配合测试人员回归支付流程 - 整理优惠券规则到需求文档模型生成的内容其实比我自己标的流水账规范多了我只需要扫一眼改改细节就能发出。这里也有一个关键心得流水账写得越具体AI 整理的效果越好。如果你只写“今天处理支付 bug”那 AI 也只能给你整出“处理支付 bug”这种没什么信息量的话。记录的时候多写一个原因、一个结果输出质量就完全不同。如果一周下来积累了五篇日志你还可以用类似的提示词让 AI 汇总生成周报。我一般周五下班前跑一次把五天的 Markdown 丢进去一两分钟就得到一版周报初稿再做点微调就提交。3.3 架构图模板用自然语言生成 Mermaid 代码画架构图是这套模板里最让我惊喜的场景。传统方式是用 draw.io 或者 ProcessOn 手动拖拽一个微服务架构图画下来怎么也要十来分钟。而现在我只需要描述清楚模块和关系剩下的交给 AI。比如我在草稿里写画一个微服务架构图包含网关、认证服务、订单服务、商品服务、用户服务、支付服务以及共用的 MySQL 和 Redis。 外部用户通过网关访问各服务服务之间通过 HTTP 调用所有服务共用数据库和缓存。配置好架构图模板后运行python scripts/ai_diagram.py drafts/订单系统架构.md模型生成的 Mermaid 代码大致是这样mermaid graph TB User[外部用户] -- Gateway[API网关] Gateway -- Auth[认证服务] Gateway -- Order[订单服务] Gateway -- Product[商品服务] Gateway -- UserSrv[用户服务] Gateway -- Pay[支付服务] Order -- MySQL[(MySQL)] Product -- MySQL[(MySQL)] UserSrv -- MySQL[(MySQL)] Pay -- MySQL[(MySQL)] Order -- Redis[(Redis)] Product -- Redis[(Redis)] UserSrv -- Redis[(Redis)] Pay -- Redis[(Redis)] Auth -- Redis[(Redis)]把这段代码粘贴进任意支持 Mermaid 的 Markdown 编辑器或笔记软件里立刻渲染成图。如果对布局不满意比如想突出某个模块直接在文字描述里加一句“订单服务是核心把它画在中间”AI 会调整关系布局。**画图的门槛从“熟练操作画图软件”降到了“把脑子里的关系说清楚”**这个改变是很本质的。 ### 3.4 三段提示词的核心差异 三个场景的提示词虽然都放在 config/prompts 下但各有侧重。笔记整理的关键词是“提炼”和“结构化”要求模型输出标签、摘要、建议目录日志生成的关键词是“客观”和“待办可见”要求模型忠于原始记录不夸张不遗漏架构图生成的关键词是“只输出代码”严格控制输出格式。 写过一段时间之后我给所有提示词都加了一条铁律**如果要处理结果能自动化落地就必须明确规定输出格式否则 AI 的“自由发挥”会带来大量手工修正成本**。尤其是架构图模型特别喜欢在代码前后加一句“以下是根据你的需求生成的架构图”这句话一旦进入文件渲染就会失败。 ## 4. 环境搭建与实操过程记录 ### 4.1 三步完成环境准备 说再多不如直接跑起来。环境准备总共三步大概十分钟能搞定。 **第一步安装 Ollama 并拉取模型。** 去 Ollama 官网下载对应系统的安装包装完在终端确认一下版本 bash ollama --version然后拉取开源模型。我日常用的是阿里的 Qwen2.5 系列7B 参数版本在笔记和日志场景下表现已经足够好16G 内存的 Mac 跑起来也不吃力。ollama pull qwen2.5:7b如果你的电脑配置一般用 3B 版本也能跑速度更快只是文本归纳的精细度会略差一点。我的建议是先拉 3B跑通流程后再换 7B感受一下差异没必要一上来就追求大参数模型。第二步克隆模板仓库并安装依赖。模板仓库是开源的直接克隆到本地git clone https://github.com/yourname/ai-workflow-template.git cd ai-workflow-template pip install -r requirements.txtrequirements.txt 里其实就是 OpenAI 的 Python SDKOllama 兼容 OpenAI 接口、PyYAML 和 requests没有其他重依赖。第三步修改模型配置。打开 config/model_config.yamlmodel: qwen2.5:7b base_url: http://localhost:11434/v1 temperature: 0.3 max_tokens: 2048base_url 指向本地 Ollama 服务temperature 设 0.3 是为了让输出更稳定、更少发散。如果你之后想用在线模型只需要把 base_url 和目标模型名换掉模板代码完全不用动。4.2 实操演示一条命令完成笔记整理环境准备好之后实操非常简单。我这里完整走一遍笔记整理的流程日志和架构图的操作完全一样。新建草稿文件 drafts/项目讨论.md写入零散内容。然后运行python scripts/ai_notes.py drafts/项目讨论.md脚本会先打印读取到的文本然后调用本地模型最后在终端输出处理结果。整个处理过程在我的 MacBook 上大概需要 10 到 20 秒取决于模型大小和内容长度。跑完后当前目录下会多出一个outputs/notes/项目讨论_整理.md文件里面就是 AI 结构化之后的版本。日志和架构图同理命令分别是python scripts/ai_journal.py drafts/今日流水账.md --date 2025-01-08 python scripts/ai_diagram.py drafts/订单系统描述.md我日常的使用习惯是白天想到什么就随手记晚上统一跑一遍三条命令几分钟内把当天所有笔记、日志、图表初稿全部生成好第二天早上抽出十分钟检查修正。AI 负责熬大夜我负责微调这套节奏让我处理文档的效率提升了至少一倍。4.3 关键参数说明与调优建议不同的使用场景对参数的要求其实不一样。我整理了一个参数速查表方便你对照调整参数笔记整理工作日志架构图生成说明temperature0.30.20.1数值越低输出越稳定架构图建议最低max_tokens204820484096架构图代码较长需要更多空间模型qwen2.5:7bqwen2.5:7bqwen2.5:7b显存不足可用 3b 替代输入长度不限建议 2000字建议 1000字输入过长时摘要质量明显下降temperature 是我调整最多的参数。一开始我把它设成 0.7模型“创意”很强但容易出现文字风格忽好忽坏、输出格式偶尔跑偏的问题。后来把笔记和日志都降到 0.3 以下架构图甚至降到 0.1效果立刻稳定了。注意“稳定”有时候比“聪明”更重要因为这套模板的价值是可复现不是偶发的惊艳输出。5. 常见问题与避坑指南5.1 常见问题速查表用了一个多月我遇到过不少问题有些是模型本身的有些是模板设计的这里整理成表格方便你快速排查问题可能原因解决办法模型响应特别慢模型过大或机器配置不足换 3b 模型关闭其他占用内存的程序输出格式总是乱掉temperature 设太高降到 0.2 以下检查提示词是否明确了输出结构架构图渲染失败Mermaid 代码中包含解释文字提示词中强调“只输出代码块”手动删除多余文字生成内容被截断max_tokens 太小调大到 4096 或 8192脚本报错“连接被拒绝”Ollama 服务未启动终端执行ollama serve启动服务AI 分类不准确输入文本太简短、上下文不足在模板中补充背景信息字段比如项目名称、关联目标5.2 实际操作中踩过的几个坑第一个坑发生在架构图场景。我最初用的提示词是“请生成微服务架构图代码”没有强调“只输出代码”结果模型每次都会在代码前加一句“这是为您生成的架构图”导致我必须在代码块里手动删除这些文字。后来把提示词改成“只输出 Mermaid 代码不要包含任何解释或前后缀”问题就不再出现了。这个教训我后来用在了所有场景的提示词里。第二个坑是贪图大模型。一开始我用 qwen2.5:32b生成质量确实更好但响应时间翻了三四倍每处理一篇笔记要等一分钟以上非常消磨耐心。换了 7b 之后质量差距并没有想象中那么大但速度提高了三倍体验完全不在一个级别。选模型不是越大越好而是要在质量和速度中间找平衡。第三个坑是把 AI 输出结果直接当成最终产物。有一段时间我偷懒AI 生成的工作日志看都不看就提交。直到有一天模型把一条“修复了登录失效问题”整理成“解决了用户无法登录的严重故障”语气过度严重差点引发误会。从那以后我养成了一个习惯AI 输出的内容尤其是对外发送的必须过一遍人眼。它最大的价值是帮你省掉“从零到一”的时间但“从一到十”的判断还得自己来。第四个坑是没注意到输出文件的目录路径。第一次运行脚本时输出文件直接生成在源目录下和我草稿混在一起时间一长非常乱。后来我在脚本里把所有输出统一重定向到outputs/目录按日期分文件夹存放问题才解决。如果你自己改造模板建议从一开始就把输入、输出、模板目录严格分开。5.3 我的使用心得AI 工作流的真正边界最后说点个人体会。这套模板用久了我对“AI 提升生产力”的理解发生了不小的变化。以前总觉得 AI 应该去做那些“高难度”的事比如自动生成完整方案、直接写代码后来发现它最擅长的其实是那些重复、琐碎、不需要太多创造力但是必须做的结构化工作。整理笔记格式、写日报框架、把文字描述翻译成图形代码这些事看起来很小但每天都在消耗注意力。省下这些时间之后我才有更多精力去做真正需要判断和创意的事情。这套模板的扩展空间也很大比如定时任务加上一个 cron每天下班自动跑日志生成再比如把输出目录接入网盘同步手机和电脑随时都能看到甚至可以把架构图模板进一步拆细增加部署架构图、网络拓扑图等专门模板。工具本身不值钱值钱的是你愿不愿意花一个下午把流程理顺。整理这套模板花了我一个晚上但它省下来的时间早已远超一个晚上。