说实话我以前的笔记习惯挺乱的。灵感来了随手塞进手机备忘录开会内容散落在聊天记录里架构图更是打开绘图软件一张张拖框拖出来的改一次需求就得重新拉半天线。后来我干脆自己整理了一套免费开源的工作流模板把记笔记、写日志、画架构图这三件高频又琐碎的事全部统一成“一个模板 一段提示词 一个脚本”的流程实测下来效率提升非常明显。这套东西不依赖任何商业化产品数据全部留在本地核心逻辑也很简单Markdown 文件做数据层脚本做调度层AI 只负责理解和生成内容。如果你平时也需要维护个人知识库、写日报周报或者经常要给系统画架构图那这篇内容应该能帮到你。我会从设计思路、目录结构、实操步骤到踩坑经验全部拆开讲所有示例代码都能直接抄走用。1. 这个模板到底做了什么1.1 三个高频场景的一体化方案这套模板本质上做的事情只有一件把“写东西、存东西、画图”这三类日常工作从手工操作变成半自动化流程。第一是笔记管理。平时我在聊天记录里看到一段有用的方案或者脑子里闪过一个产品想法会先丢进一个固定的收件箱文件然后让 AI 把这些碎片信息整理成结构化笔记。它会把一段口语化的描述转成“背景、问题、方案、待确认”这种清晰的小节并且自动补上标签和关联概念方便后续检索。第二是写日志。我以前写日志最大的问题是坚持不下来因为每天打开空白文档不知道从哪写起。模板里内置了一个日志格式分今天做了什么、遇到什么阻塞、明天计划是什么、有什么想法每天只需要往里填几句话。到了周五脚本会把这一周的日志拼起来交给 AI 自动生成周报不用再对着空文档憋字。第三是架构图生成。我只需要用自然语言描述系统里有哪几个服务、它们之间怎么调用、数据怎么流转AI 就能生成对应的架构图代码。这个代码是文本格式直接在 Markdown 里渲染就变成架构图改图和改代码一样方便不再需要拖拽框线。这三个场景看起来差别很大但背后的逻辑是相通的先用一套约定好的格式承接信息再用 AI 做信息处理和表达转换最后用脚本把重复劳动自动化。1.2 为什么不用现成笔记应用而是自己攒一个模板很多人可能会问Notion、Obsidian 这些工具不也能干这些事吗其实我一开始也用过但用久了就会发现几个绕不开的问题。首先是数据所有权。笔记和文档是长期积累的资产放在某个商业应用里随时可能遇到调整收费策略、功能下线或者数据迁移困难的问题。而这种纯文本方案所有文件都在自己硬盘上用 Git 管理想搬到任何地方都可以永远不会被绑架。其次是灵活性。完整应用的流程是固定的AI 集成、图表生成这些功能都得等官方更新但我自己维护模板提示词可以随时调脚本可以随时改工具链可以随时换。今天用云端 API明天换本地模型只需要改一个配置文件不用改变工作习惯。还有一个很重要的点是成本。这个方案不需要服务器、不需要数据库、不需要订阅任何软件所有脚本都是本地跑。AI 部分既可以用云端 API 按量付费也可以接本地开源模型完全免费丰俭由人。所以这套模板的定位不是要替代成熟应用而是给那些希望“自己掌控工作流程”的人一个起步框架。2. 模板的整体设计与目录结构2.1 项目目录与每个文件的职责整个项目结构非常清晰我直接贴出来给你看每个目录干一件事没有多余的东西。ai-notes-workflow/ ├── templates/ │ ├── daily-log.md # 每日日志模板 │ ├── meeting-notes.md # 会议纪要模板 │ ├── note.md # 知识笔记模板 │ └── architecture.md # 架构图生成模板 ├── scripts/ │ ├── new_log.sh # 创建当天日志文件 │ ├── weekly_report.py # 汇总一周日志生成周报 │ ├── ai_task.py # 通用 AI 调用脚本 │ └── gen_arch.py # 自然语言转架构图脚本 ├── prompts/ │ ├── log_writer.md # 日志整理提示词 │ ├── note_summarizer.md # 笔记整理提示词 │ ├── weekly_report.md # 周报生成提示词 │ └── arch_generator.md # 架构图生成提示词 ├── content/ │ ├── inbox.md # 碎片信息收件箱 │ ├── logs/ # 按日期存放日志文件 │ ├── notes/ # 整理后的知识笔记 │ └── diagrams/ # 生成的架构图代码 └── config.yaml # 模型、API Key、路径配置每个文件都不是摆设。templates/里是内容格式约定告诉你和 AI“这篇文档应该长什么样”scripts/里是调度逻辑负责创建文件、调用模型、写回结果prompts/里是最核心的部分相当于给 AI 的“岗位说明书”每个场景对应一份独立的提示词content/是实际数据目录inbox 是入口其他目录是归档出口。config.yaml用来集中管理模型参数这个设计很关键。换模型的时候不用改任何脚本只改这个文件就行。我后面会详细讲每个参数怎么配。2.2 为什么用 Markdown frontmatter 做数据层模板里所有内容文件都是 Markdown 格式并且在文件头部加了一段 frontmatter 元信息。比如一个日志文件开头是这样的--- date: 2025-04-23 tags: [工作日报, 前端] mood: 正常 --- ## 今日完成 - ... ## 阻塞问题 - ... ## 明日计划 - ...这个设计不是随手拍脑袋定的它有非常实际的好处。第一Markdown 是纯文本任何设备、任何编辑器都能打开不需要专用软件。就算过了十年文件也不会因为软件停运而打不开。第二frontmatter 是脚本和 AI 之间共享的结构化“接口”。脚本可以直接用 Python 的 yaml 库读取日期和标签用来做周报筛选AI 在读文件时也能一眼识别出上下文不需要猜测这一篇是什么时间的记录。第三AI 对 Markdown 的理解非常强。因为大模型训练语料里 Markdown 占比极高它天然理解标题层级、列表、引用这些语法。给它一份结构化模板它输出的内容就会自动保持结构比让它自由发挥稳定得多。这里有个很重要的“二八法则”80% 的整理收益来自统一的格式约定而不是复杂的系统设计。你不需要一开始就搭数据库、做双向链接先把“标题写清楚、日期写清楚、标签写清楚”这三件事做到知识管理的效率就已经超过大多数人了。2.3 提示词文件怎么设计提示词文件是整个模板的灵魂我单独用.md文件存放而不是写在脚本里因为提示词需要经常改、需要记录版本。比如prompts/log_writer.md里是这样组织的你是一名严谨的编辑助理。你的任务是把用户的碎片信息整理成工作日志。 要求 1. 按时间顺序归类事项 2. 每条事项用一句话概括不超过30字 3. 如果提及问题归入“阻塞问题”小节 4. 如果信息不足用“待补充”标注 5. 输出格式必须与模板保持一致禁止额外发挥 模板参考 --- ## 今日完成 - [事项描述] ## 阻塞问题 - [问题描述] ## 明日计划 - [计划描述] ---注意提示词里写清楚了“禁止额外发挥”这是一个很关键的细节。AI 在自由模式下容易把日志写成小作文但日志的核心价值是信息密度和可检索性不是文笔。把输出边界划清楚比让 AI 尽情发挥实用得多。脚本读取这个提示词文件把它和用户输入拼在一起发给模型返回结果写回文件。这样提示词和逻辑分离你想调整 AI 行为只需要改 Markdown 文件不用看代码。3. 实操把 AI 接入笔记与日志流程3.1 初始化与创建每日日志先把项目克隆到本地然后装依赖。这个项目的脚本主要用 Python 标准库加速对PyYAML和requests或openaiSDK安装很简单cd ai-notes-workflow pip install pyyaml requests cp config.example.yaml config.yamlconfig.yaml里的核心配置长这样llm: provider: openai # 可选 openai / ollama model: gpt-4o-mini api_key: sk-xxx # 云端 API 需要本地模型留空 base_url: https://api.openai.com/v1 temperature: 0.2 max_tokens: 2000 paths: inbox: content/inbox.md logs: content/logs notes: content/notes diagrams: content/diagrams配置好之后每天写日志只需要跑一条命令./scripts/new_log.sh这个脚本做的事情很简单读取昨天日志文件里的“明日计划”自动填到今天日志文件的“今日计划”里同时用templates/daily-log.md生成带今天日期的新文件。这样每天打开就是昨天的待办事项不用每次都从空文件开始。我强烈建议把这个命令设置成终端别名或者自动化快捷键比如在.bashrc里加一行alias log~/ai-notes-workflow/scripts/new_log.sh。每天开工先执行一下三秒钟完成初始化写日志这件事就成功了一半。3.2 AI 整理碎片笔记的完整流程日志解决的是“今天做了啥”笔记解决的是“我学到的东西怎么沉淀”。这里的核心流程是先用 inbox 收集碎片再由 AI 整理归档。平时有灵感或者看到好内容不要立刻打开笔记软件开始排版先花十秒钟把原始信息丢进content/inbox.md像这样# 2025-04-23 - user 提到支付超时可能和 redis 连接池占满有关 - 我们目前没有重试机制失败直接返回报错 - 参考方案信号量限流 指数退避重试到了晚上或者周末运行这条命令python3 scripts/ai_task.py \ --task note_summarizer \ --input content/inbox.md \ --output content/notes/2025-04-23-payment-timeout.md脚本会把 inbox 里当天的内容抽取出来和prompts/note_summarizer.md拼在一起发给 AI返回结果写入输出文件。处理完之后inbox 里已处理的部分会被标记为归档状态避免重复整理。这里有一个实操中的经验一次喂给 AI 的内容量不要太大。很多人想让 AI 一口气整理一周的碎片结果笔记生成得很空因为信息太多之后模型容易抓不住重点。我建议每次只处理一天的碎片或者控制在 500 字以内。输入质量高输出质量才有保证。3.3 自动生成周报的脚本实现周报是我以前最抗拒的写作任务现在完全交给脚本自动跑。scripts/weekly_report.py的逻辑分三步收集、拼接、总结。第一步收集最近一周的日志文件按日期从content/logs/读出来。第二步把日志内容拼接成一个临时文本注意拼接顺序要按日期从周一到周日否则 AI 生成的周报时间线会乱。第三步调用模型让 AI 把流水账转成周报形式。核心代码大概长这样import yaml import requests from pathlib import Path def load_config(): with open(config.yaml, r, encodingutf-8) as f: return yaml.safe_load(f) def collect_logs(logs_dir, days7): log_files sorted(Path(logs_dir).glob(*.md))[-days:] content [] for f in log_files: content.append(f## {f.stem}\n{f.read_text(encodingutf-8)}) return \n.join(content) def generate_report(messages): cfg load_config()[llm] resp requests.post( f{cfg[base_url]}/chat/completions, headers{Authorization: fBearer {cfg[api_key]}}, json{ model: cfg[model], temperature: cfg[temperature], max_tokens: cfg[max_tokens], messages: messages, }, ) return resp.json()[choices][0][message][content] if __name__ __main__: cfg load_config() logs_content collect_logs(cfg[paths][logs]) prompt_template Path(prompts/weekly_report.md).read_text() messages [ {role: system, content: prompt_template}, {role: user, content: logs_content}, ] report generate_report(messages) print(report)看到没有整个脚本很短没有复杂的框架就是把文件读出来、发请求、拿结果三个动作而已。如果你想省钱周报这种周期性任务不需要用很强的模型小模型出的结果通常也够用关键还是日志质量要跟上。4. 架构图生成的原理与配置细节4.1 LLM 为什么能“凭空”画出架构图先解决一个很多人疑惑的问题AI 又不长眼睛它怎么“画”图答案很简单它生成的不是像素而是描述图形关系的文本代码。目前最常用的方案是生成 Mermaid 语法代码这是种专门用文本描述图表的语言比如要画一个简单的流程图可以写成graph TD; A[网关] -- B[订单服务]这样一行字渲染工具会把它变成带箭头的框图。AI 在训练的时候看过海量这种代码它非常擅长根据一段自然语言描述生成对应的结构化代码。因为架构图本质上就是一种“节点 关系”的树状结构这恰恰是大模型最擅长的信息组织方式。你可以把生成架构图的流程理解成“用文字画草图”先描述系统里有什么模块再说模块之间怎么连接让 AI 补全细节。这个模式比手工拖拽画图快得多也方便版本管理——每次修改都是文本 diff谁在什么时候改了哪条线一清二楚。4.2 让 AI 稳定输出 Mermaid 代码的提示词模板要让 AI 稳定输出代码提示词必须限定格式。我的prompts/arch_generator.md是这样的你是一名系统架构师。根据用户描述生成 Mermaid 架构图代码。 要求 1. 只输出 Mermaid 代码块不要任何解释文字 2. 先定义子图subgraph表示模块分组 3. 节点命名用英文显示文字用中文 4. 连线关系要完整不要遗漏用户提到的所有依赖 5. 如果信息不足在代码注释中标注 TODO 示例 graph TD subgraph 客户端层 A[Web前端] B[移动端] end subgraph 服务层 C[网关] D[订单服务] E[支付服务] end A -- C B -- C C -- D C -- E对应命令是python3 scripts/gen_arch.py 用户通过前端下单订单服务调用支付服务支付回调写入消息队列队列消费更新订单状态脚本会调用模型把返回的 Mermaid 代码清洗后写入content/diagrams/目录下的.md文件。这里有几个容易踩的坑我提前标出来。第一不要省略“只输出代码”这句话否则 AI 会在代码前后加一堆“以下是”“好的”之类的废话对后续处理造成麻烦。第二节点名用英文、显示文字用中文这个约定很重要因为很多渲染器对中文节点名兼容性不太好尤其是引用了特殊符号时容易报错。第三如果架构比较复杂建议让 AI 先输出一个主干再逐步补细节一次性生成超大规模图容易出现漏连线或者结构失衡。4.3 渲染与嵌入 Markdown 的两种方式生成 Mermaid 代码之后需要把它变成真正能看的图。最省事的办法是直接在 GitHub 或 GitLab 上查看这两个平台原生支持 Markdown 里的 Mermaid 渲染把代码提交上去浏览器里直接显示图形。本地也有两个常用方案。一个是 VS Code 安装 Markdown Preview Mermaid Support 插件在编辑 Markdown 的时候预览窗口会显示架构图另一个是用命令行工具把.md文件导出成 PNG 或 SVG适合需要放在文档或者 PPT 里使用。我的习惯是架构图代码统一放在content/diagrams/目录下每个图单独一个 Markdown 文件正文里写清楚这张图描述的是什么场景。这样看代码有上下文渲染也有结果比甩一张图片在文档里好维护多了。“文本即图”带来的额外好处是评审效率提升。以前团队评审架构图每个人都在各说各的版本现在直接看代码 diff改了一个节点、加了一条依赖一目了然。这个过程非常自然。4.4 模型选型与关键参数控制架构图生成对模型的要求比日志整理高一些因为代码输出必须严格遵循 Mermaid 语法模型如果自创语法渲染工具不认。云端 API 我推荐用带较强代码能力的模型冷启动时 temperature 调到 0.1 或 0.2这个参数控制随机性生成代码时最好接近“填空”而不是“创作”。max_tokens也要给够架构图生成比普通文本更耗 token设置太短会导致代码被截断后半截全没了。如果你更在意数据隐私或者不想花钱本地模型也是不错的选择。最推荐的组合是 Ollama 加 Qwen2.5-Coder 或 DeepSeek-Coder 系列中英文混合理解能力不错生成的 Mermaid 代码质量也能达到可用标准。本地模型的缺点是生成速度慢一些普通电脑跑小参数模型还行跑大模型可能需要等待十几秒。最后一个参数是base_url很多开源模型都兼容 OpenAI 接口格式只需要把地址改成本地服务地址就行。这个设计可以让你轻松在云端和本地之间做切换不影响其他脚本逻辑。5. 常见问题与排查技巧实录5.1 AI 生成的架构图渲染报错这个是最常见的问题没有之一。症状很统一AI 生成了代码放进去渲染提示语法错误。问题原因大多是出在 Mermaid 语法的边界情况上。我统计过最常见的三类错误第一节点文字里包含括号或者冒号比如A[用户服务(新)]渲染器会误判解决办法是把特殊符号换成全角符号或者用引号包住节点名。第二中英文混排时引号不匹配比如用了中文引号而不是英文引号这种错特别隐蔽。第三子图缺少结束标记生成复杂架构时 AI 容易漏写end。排查技巧是先把 AI 生成的代码单独复制到一个空白 mermaid 渲染器里跑看具体报错信息。确认是哪一行有问题再把错误反馈给 AI 让它自己修复。这比手工改代码省力得多因为 AI 看到报错信息通常能自己定位问题。5.2 AI 输出的日志风格飘忽不定有时候周一生成的日志很简洁周三突然变成一整段小作文格式也不统一。这个问题的根源通常不是模型不稳定而是提示词里给的参考模板不够具体。解决办法有两个。第一个是在提示词里明确给出“好例子”和“坏例子”直接告诉 AI 输出长度不能超过 5 行、每条事项不能超过 30 字。第二个是在config.yaml里降低 temperature 参数减少随机性。我实测下来日志任务 temperature 设置在 0.2 左右最合适低于 0.1 会显得机械高于 0.5 就天马行空。还有一种情况是换了模型之后风格变化明显这属于正常现象。不同模型的写作偏好不同建议每次换模型后先跑几天日志观察一下风格是不是你能接受的范围再确定要不要正式切换。5.3 周报脚本漏内容周报生成后发现某天的工作没被统计进去排查方向有两个。第一是日志文件名是否规范。我脚本里用的是YYYY-MM-DD.md格式如果你手动创建了文件名带其他前缀就无法被 glob 匹配到。这个检查起来最简单直接打开目录看一眼文件名就行。第二是拼接内容太长导致 token 截断。如果一周的日志加起来超过模型的上下文限制AI 只会看到前面的内容最后几天的数据就丢了。解决办法是分段汇总每天先做一次摘要最后把摘要拼起来生成周报这样每一层的输入都足够小信息也不会丢失。我在实践中一般把单段拼接内容控制在 2000 字以内超过就自动化分块每块生成摘要再汇总。5.4 数据备份与隐私注意点所有内容都是本地文件备份就变得非常简单。我直接把整个项目目录做成 Git 仓库每次整理完笔记或者生成完周报提交一次就行。这样不仅解决了备份问题还能回滚某天的修改记录非常实用。隐私方面如果用云端 API注意日志和笔记里的敏感信息会被发送到第三方模型服务最好在发送之前做脱敏处理。如果涉及公司内部敏感数据建议切换到本地模型方案靠 Ollama 之类的工具在本地推理数据完全不出内网。我在模板里加了一个前置脚本检测到内容里包含电话、邮箱、身份证号之类的模式时会自动打码这个逻辑很简单就是用正则替换但能避免很多不必要的泄露风险。6. 还能怎么玩扩展思路与个人体会6.1 从个人到团队的扩展玩法这套模板不只是个人效率工具稍微改造一下就能服务小团队。最实用的扩展方向是会议纪要自动生成待办。把会议纪要模板里加上“行动项”小节AI 在总结完讨论内容后自动提取出“谁在什么时间之前完成什么事”这些待办可以继续接入到待办清单里。团队里每个人的周报也可以共用同一个脚本只需要让模型按人筛选日志文件就行产出完全是自动化的。另一个方向是做故障复盘。把事故描述填入模板AI 按照“现象、影响、根因、修复措施、后续预防”五个角度生成复盘文档比自己对着事故记录瞎写结构清晰很多。尤其是团队要求每次事故都有复盘报告的时候这个模板能帮你节省大量排版时间。6.2 我踩过的几个坑最后分享几个我实际踩过坑之后的经验总结希望能帮你少走弯路。第一不要追求一步到位自动化。刚开始用的时候我试图把所有环节都接上 AI结果各种小问题不断反而比手工还慢。正确做法是先手写模板两周把格式习惯养成了再逐步加 AI 辅助最后才加自动脚本。第二提示词一定要纳入版本管理。我吃过一次亏改了一版提示词之后输出的笔记风格完全变了后来回滚才发现旧版本没保存。现在所有prompts/目录都用 Git 管理每改一版写清楚改动原因这样出了任何问题都能立刻恢复到上一个稳定版本。第三AI 生成的架构图不要直接照搬尤其是涉及技术选型的场景。模型擅长的是组织结构和表达不代表它比你更懂业务约束。我一般让 AI 产出初稿用它作为讨论基础再自己动手调整关键节点和依赖关系这个模式最高效。第四所有脚本尽量保持简单不要引入不必要的框架依赖。这个模板能稳定运行很久正是因为它只有几个 Python 文件和 shell 脚本没有复杂的服务、没有数据库、没有魔法。技术栈越简单长期维护成本越低。如果你也想搭一套这样的流程我建议别从头开始设计完整方案先从每日日志开始跑两周把格式习惯养成了再逐步加笔记整理和架构图生成。工具这东西用起来了才是效率提升放在收藏夹里永远只是一堆代码。