如果你和我一样手里攒了一堆草稿、会议记录、随手记的灵感但每次想交给 DeepSeek 整理都得打开网页端粘贴、复制、再粘贴那我建议你试试 DeepSeek Harness v0.2 桌面端。我花了一晚上把环境跑通之后第二天用 30 分钟搭出第一个能真正出活的 AI 工作流读取本地草稿文件自动生成周报保存成 Markdown。整个过程不用写代码。这个工具说白了就是给 DeepSeek 模型套了一个可视化工作流外壳把“读文件→写提示词→调用模型→保存结果”这些步骤做成节点在桌面上拖拖拽拽就能串起来。适合不想维护一堆脚本、也懒得部署 Web 服务的人如果你要处理的是批量文本整理、日常总结、内容改写这类重复劳动它比在网页端一次次手动操作要省事得多。1. v0.2 桌面端解决了什么问题为什么我放弃裸调 API 和网页复制粘贴1.1 裸调 API 的重复劳动比想象中更磨人我最早用 DeepSeek 的方式很简单——直接写 Python 调接口。效果虽然稳定但麻烦也是真麻烦每个任务都要写一段请求脚本token 计数要自己算超了上下文窗口就得截断。返回的 JSON 里 content 可能带着奇怪的转义字符清洗逻辑写了一套又一套。单个请求还好一旦要做“先总结、再改写、再翻译”这种多步骤任务代码就变成意大利面。这种重复劳动一次两次能忍天天做就很烦。后来试过在网页端手动操作结果更尴尬——复制粘贴的环节特别容易出错比如漏了一段、贴错了文本而且每一步的思维链都断掉了想回溯都不知道哪一步出了问题。1.2 DeepSeek Harness 到底是个什么东西DeepSeek Harness v0.2 的定位我理解成“本地优先的 DeepSeek 工作流编排器”。它把一次 AI 处理拆成多个节点文件读取、提示词模板、模型调用、结果输出节点之间用连线确定数据流向点击运行工作流就顺着链路跑一遍。界面有点像常见的低代码平台但它是桌面应用不需要启动服务器数据也不会传到无关的服务器上——除了真正调用 DeepSeek 接口那一步你的中间结果都留在本机。这一点对我来说特别重要因为我的草稿和会议记录基本都包含内部信息。模型配置这块v0.2 默认就是 DeepSeek 官方接口填一个 API Key 就能用。它也兼容市面上常见的 OpenAI 风格接口也就是说如果哪天你想切换成别的模型服务商只要对方提供兼容接口改个 base_url 和模型名就行节点不需要重画。1.3 和 Dify、Flowise 的差异为什么桌面端值得一试之前我也折腾过 Dify 这类服务但说实话它们更适合部署在服务器上给团队用个人电脑上跑一个 Docker 容器内存占用有点夸张。Flowise 倒是轻但安装和命令行操作对非程序员来说还是有点门槛。DeepSeek Harness v0.2 走的是另一个路线下载安装包下一步下一步打开就是一个窗口。它对标的使用场景不是“企业 AI 平台”而是“个人电脑上的 AI 工具箱”。而且它启动很快我之前用某款桌面端工具光是打开就要转半天这个从双击到出界面大概 5 秒。这种小差异在每天高频使用下感受非常明显。2. 安装与首登v0.2 的 3 个坑和 2 个官方没写的配置2.1 安装包选择与安装路径我下载的是 Windows 版压缩包大概 280MB解压后是一个 DeepSeekHarness 文件夹。建议解压到不含中文、不含空格的路径比如 D:\Tools\DeepSeekHarness——之前遇到过因为路径带空格导致某些内置脚本找不到配置文件的情况。解压完先别急着点开各种程序确认一下目录里有 dsh-gui.exe 或者 dsh-cli.exe。v0.2 的图形界面入口是 dsh-gui.exe命令行工具是 dsh-cli.exe这两个是同一个程序的两面。首次运行会生成一个配置文件在 Windows 上是 %APPDATA%\dsh\config.yamlLinux 和 macOS 上则是在 ~/.config/dsh/config.yaml。2.2 首次启动容易卡住的配置第一次打开界面会看到一个设置页要填的是API Key在 DeepSeek 开放平台申请填到设置里。Model Name默认是 deepseek-chat这个不用改。Base URL默认是 https://api.deepseek.com没有特殊需求也别改。填完点保存界面右上角会变成绿色状态表示连接成功。如果一直是红色先去确认这台机器能不能正常访问 api.deepseek.com再检查 API Key 是否复制完整了——我见过好几个人把 Key 末尾的空格一起复制进去导致鉴权失败。2.3 坑一默认参数对中文输出很不友好这里要重点说一个官方文档里没强调的问题。v0.2 安装后新建模型节点的 temperature 默认是 0.8max_tokens 默认是 2048。用 0.8 跑中文总结结果经常会发散句子绕着圈子说甚至自己加戏。我后来统一改成 0.3输出立刻变得紧凑。所以第一次跑完觉得“AI 说废话”的先别急着删工具先看看参数是不是没调。2.4 坑二本地文件读取默认是关闭的v0.2 新增了 read_file 节点可以读取本地 txt、md、pdf、docx 文件。但默认权限是关闭的——这也是桌面端工具常见的安全策略。第一次用 read_file 节点它会弹一个授权请求询问是否允许访问这个文件。要点“允许”之后才能读取。如果你点错了“拒绝”后面在节点设置里可以重新打开权限列表手动添加允许目录。2.5 坑三启动白屏或加载超时如果你打开界面发现白屏先看任务管理器里是不是已经有一个 dsh-gui 进程在跑。这个工具单实例锁做的一般双击两次可能起两个进程后启动那个会白屏。杀掉所有 dsh-gui 进程再重新启动就好。另外如果本机 7860 端口被占用也会导致页面加载不出来这个在日志里会明确提示把端口占用解决即可。2.6 官方没写的小配置输出目录和日志级别配置里有两个选项我强烈建议你改一下output_dir所有写文件类节点的默认保存路径建议改成你自己的工作目录比如 D:/work/ai-output。log_level默认是 info调试工作流时改成 debug日志会详细记录每个节点的输入输出时间很多问题一眼就能看出来。改完配置文件记得重启 dsh-gui。3. 30 分钟实操从零搭一个“草稿文件 → 总结 → 周报”工作流3.1 先想清楚链路再动手画节点我搭的工作流很简单输入一个记录了一周零散想法的 Markdown 文件输出一份结构化的周报。拆成节点就是读文件、写提示词、调用模型、保存结果。如果之前在 Dify 上画过工作流你会发现这里的思路基本一样。DeepSeek Harness 的节点类型在 v0.2 里比较精简但核心这几个都有read_file、text_template、llm、write_file、text_splitter、http_request。对一个常见内容整理场景来说read_file→text_template→llm→write_file 已经够用。3.2 第一个节点读文件在画布上拖入一个 read_file 节点双击打开配置文件路径D:/work/notes.md编码UTF-8如果文件是其他编码会乱码后面会详说排查方式输出变量名file_content运行这个节点后file_content 变量就带着整个文件内容流到下一个节点。3.3 中间节点提示词模板 LLM拖入 text_template写模板你是周报助手。下面是一周的工作草稿请整理成周报包含三部分本周完成、问题与风险、下周计划。注意保留具体数字和结论不要编造。 草稿 {{ file_content }}模板里的变量用双花括号包裹跟常见模板引擎一致。然后拖入 llm 节点模型选择 DeepSeek把提示词模板的输出接进 llm 的 prompt 输入。参数我前面说了temperature 0.3max_tokens 1200。3.4 最后一个节点保存为 Markdown拖入 write_file 节点把它接到 llm 输出上配置保存路径D:/work/weekly.md内容模式覆盖写如果你希望保留历史可以把路径改成带日期变量的形式例如 weekly-{{ date }}.md这一步我放到第 5 章再讲。3.5 点运行看三步整个工作流跑完D:/work/weekly.md 就生成了。我建议别只看最终文件运行完依次点开三个节点看输出read_file 输出有没有读到全部内容、text_template 输出里的变量有没有正确填充、llm 输出是不是你想要的格式。这样即便出问题也能立刻定位到在哪一段断了。3.6 30 分钟其实大部分花在写提示词上工具本身的拖拽连线 5 分钟就能搞定真正花时间的是写模板。我第一版模板写得太笼统输出全是“该团队本周完成了一些工作”这种废话改成“保留具体数字和结论不要编造”之后才像能直接发出的周报。所以在搭工作流的时候别急着拖节点先在文本编辑器里把提示词打磨两遍再粘进 text_template。4. 实测结果与翻车现场乱码、超长文本、格式丢失的完整排查链路4.1 翻车一读取中文 Markdown 文件全乱码我第一次跑输出文件里全是乱码。当时第一反应是模型出问题了后来冷静下来一想模型收到的 prompt 就是乱的它再厉害也只能给你输出乱码。在 read_file 节点里看到 source_preview 也是乱的立刻意识到是文件编码不对。我的笔记文件是 Windows 记事本默认的 GBK/ANSI 编码而 read_file 节点默认按 UTF-8 解码。解决办法有两个一个是把笔记另存为 UTF-8另一个是 read_file 配置里加 encoding 参数写成 gb18030。我个人推荐前者毕竟之后所有节点都默认 UTF-8统一编码能省很多事。4.2 翻车二草稿太长直接超出上下文窗口第二版试跑文件里塞了我两个月的笔记大概 1 万多字。运行到 llm 节点日志里出现 context length exceeded节点状态标红。这是大模型应用最常见的错误之一原因就是输入文本太长超过了模型上下文限制。解决思路有三种加一个 text_splitter 节点把长文本切成若干段用 map-reduce 思路分块总结再合并。精简输入只截取最近一周的内容。在 llm 节点里把模型切到上下文更大的版本。我当时选的是先切分这是最通用的做法。text_splitter 节点按字符数或者段落数切块每块 2000 字左右然后让 LLM 对每一块先做摘要再用一个 merge_prompt 节点把多个摘要合并。工作流变成 read_file→splitter→llm(分块摘要)→merge_prompt→llm(合并)→write_file。逻辑上不复杂但链路长了排查也更需要有条理。4.3 翻车三模型输出好好的保存到文件格式却不对还有一次llm 节点输出预览里 Markdown 标题、列表都正常但保存到文件后全变成了纯文本换行和 # 号全没了。这个问题的根源不在模型而在 write_file 节点的配置。v0.2 的 write_file 默认把输入当作纯文本写入不处理任何 Markdown 语法。解决方式是在 write_file 节点里开启 Markdown 渲染支持或直接保持原样写入具体看你的需求。我踩过之后才明白最终输出文件的内容和 llm 预览不一致时优先检查输出节点而不是改提示词。4.4 排查思路永远先定位到具体节点再动手上面三个翻车案例虽然现象不同但排查思路是一样的从链路头端开始逐节点看输出。read_file 不对就看文件编码text_template 不对就看变量填充逻辑llm 不对就看参数和上下文长度write_file 不对就看写入配置。千万不要跳过中间节点直接怀疑模型那样会浪费大量时间。4.5 常见错误对照表现象可能原因解决方式输出乱码源文件编码与 read_file 默认编码不一致统一保存为 UTF-8或设置 encoding 参数全部节点变红日志报 context length exceeded输入文本超过模型上下文限制加 text_splitter 切块或换更大上下文模型llm 预览正常但文件格式丢失write_file 把内容当纯文本写入检查 write_file 配置确认是否开启 Markdown 支持节点正常但最终文件没有内容文件路径或写入权限有问题检查输出目录是否存在、是否有写权限提示词模板输出没填充变量变量名拼写或花括号层级不对对照模板输出内容确认变量名双花括号闭合5. 进阶模板化 命令行调用把工作流变成每天都能用的日常工具5.1 用变量把路径和日期通用化刚搭好的工作流只能处理固定文件 D:/work/notes.md可日常用法肯定不固定。v0.2 支持在配置里使用内置变量常用的有 {{date}}、{{user}}、{{input}}。把 read_file 的路径改成 D:/work/notes-{{date}}.md再把 write_file 的路径改成 D:/work/weekly-{{date}}.md这样每天新建一个笔记文件跑一次工作流就会自动生成对应的周报文件互不覆盖。5.2 用命令行把工作流变成“一键”在 dsh-gui 里搭好的工作流其实是以 .dshflow 文件形式保存的。它会默认存在配置目录的 workflows 文件夹里。在命令行里直接运行dsh run weekly.dshflow --set inputD:/work/today.md就可以不打开图形界面直接跑工作流。更进一步把这条命令做成 Windows 计划任务或者 macOS 的 cron每天下午 5 点自动跑一遍第二天早上群里就有周报了。5.3 工作流文件可以直接复制分享这也是我挺喜欢 v0.2 的一点工作流定义是一个本地文件没有绑定用户账号你把自己的 .dshflow 发给同事对方只要也装了 DeepSeek Harness改一下路径就能跑。如果团队里有人之前折腾过把 Dify 工作流转成工程代码的事就会知道这种本地文件式的定义后续做程序化处理要省心得多。5.4 别把工作流设计得太大一条链路最好只做一件事最后说一个我自己的体会。刚开始我把总结、翻译、润色、生成待办全部塞进一条工作流结果中间环节相互影响改一个节点连带崩好几个。后来拆成三条独立的工作流summary.dshflow 负责总结translate.dshflow 负责翻译weekly.dshflow 负责周报。每条链路短、目标单一出问题也容易修。搭这个工作流到现在我每天早上的动作变成把昨日记的草稿丢进 D:/work 目录双击一下 dsh 命令行五分钟不到就拿到整理好的内容。这种把 AI 从“网页对话框”变成“本地管道”的体验确实比一次次复制粘贴舒服很多。如果你的草稿整理、会议纪要、周报生成也有类似的重复劳动可以照这个思路先搭一条最小的链路跑通了再往上加节点。
如果你和我一样手里攒了一堆草稿、会议记录、随手记的灵感但每次想交给 DeepSeek 整理都得打开网页端粘贴、复制、再粘贴那我建议你试试 DeepSeek Harness v0.2 桌面端。我花了一晚上把环境跑通之后第二天用 30 分钟搭出第一个能真正出活的 AI 工作流读取本地草稿文件自动生成周报保存成 Markdown。整个过程不用写代码。这个工具说白了就是给 DeepSeek 模型套了一个可视化工作流外壳把“读文件→写提示词→调用模型→保存结果”这些步骤做成节点在桌面上拖拖拽拽就能串起来。适合不想维护一堆脚本、也懒得部署 Web 服务的人如果你要处理的是批量文本整理、日常总结、内容改写这类重复劳动它比在网页端一次次手动操作要省事得多。1. v0.2 桌面端解决了什么问题为什么我放弃裸调 API 和网页复制粘贴1.1 裸调 API 的重复劳动比想象中更磨人我最早用 DeepSeek 的方式很简单——直接写 Python 调接口。效果虽然稳定但麻烦也是真麻烦每个任务都要写一段请求脚本token 计数要自己算超了上下文窗口就得截断。返回的 JSON 里 content 可能带着奇怪的转义字符清洗逻辑写了一套又一套。单个请求还好一旦要做“先总结、再改写、再翻译”这种多步骤任务代码就变成意大利面。这种重复劳动一次两次能忍天天做就很烦。后来试过在网页端手动操作结果更尴尬——复制粘贴的环节特别容易出错比如漏了一段、贴错了文本而且每一步的思维链都断掉了想回溯都不知道哪一步出了问题。1.2 DeepSeek Harness 到底是个什么东西DeepSeek Harness v0.2 的定位我理解成“本地优先的 DeepSeek 工作流编排器”。它把一次 AI 处理拆成多个节点文件读取、提示词模板、模型调用、结果输出节点之间用连线确定数据流向点击运行工作流就顺着链路跑一遍。界面有点像常见的低代码平台但它是桌面应用不需要启动服务器数据也不会传到无关的服务器上——除了真正调用 DeepSeek 接口那一步你的中间结果都留在本机。这一点对我来说特别重要因为我的草稿和会议记录基本都包含内部信息。模型配置这块v0.2 默认就是 DeepSeek 官方接口填一个 API Key 就能用。它也兼容市面上常见的 OpenAI 风格接口也就是说如果哪天你想切换成别的模型服务商只要对方提供兼容接口改个 base_url 和模型名就行节点不需要重画。1.3 和 Dify、Flowise 的差异为什么桌面端值得一试之前我也折腾过 Dify 这类服务但说实话它们更适合部署在服务器上给团队用个人电脑上跑一个 Docker 容器内存占用有点夸张。Flowise 倒是轻但安装和命令行操作对非程序员来说还是有点门槛。DeepSeek Harness v0.2 走的是另一个路线下载安装包下一步下一步打开就是一个窗口。它对标的使用场景不是“企业 AI 平台”而是“个人电脑上的 AI 工具箱”。而且它启动很快我之前用某款桌面端工具光是打开就要转半天这个从双击到出界面大概 5 秒。这种小差异在每天高频使用下感受非常明显。2. 安装与首登v0.2 的 3 个坑和 2 个官方没写的配置2.1 安装包选择与安装路径我下载的是 Windows 版压缩包大概 280MB解压后是一个 DeepSeekHarness 文件夹。建议解压到不含中文、不含空格的路径比如 D:\Tools\DeepSeekHarness——之前遇到过因为路径带空格导致某些内置脚本找不到配置文件的情况。解压完先别急着点开各种程序确认一下目录里有 dsh-gui.exe 或者 dsh-cli.exe。v0.2 的图形界面入口是 dsh-gui.exe命令行工具是 dsh-cli.exe这两个是同一个程序的两面。首次运行会生成一个配置文件在 Windows 上是 %APPDATA%\dsh\config.yamlLinux 和 macOS 上则是在 ~/.config/dsh/config.yaml。2.2 首次启动容易卡住的配置第一次打开界面会看到一个设置页要填的是API Key在 DeepSeek 开放平台申请填到设置里。Model Name默认是 deepseek-chat这个不用改。Base URL默认是 https://api.deepseek.com没有特殊需求也别改。填完点保存界面右上角会变成绿色状态表示连接成功。如果一直是红色先去确认这台机器能不能正常访问 api.deepseek.com再检查 API Key 是否复制完整了——我见过好几个人把 Key 末尾的空格一起复制进去导致鉴权失败。2.3 坑一默认参数对中文输出很不友好这里要重点说一个官方文档里没强调的问题。v0.2 安装后新建模型节点的 temperature 默认是 0.8max_tokens 默认是 2048。用 0.8 跑中文总结结果经常会发散句子绕着圈子说甚至自己加戏。我后来统一改成 0.3输出立刻变得紧凑。所以第一次跑完觉得“AI 说废话”的先别急着删工具先看看参数是不是没调。2.4 坑二本地文件读取默认是关闭的v0.2 新增了 read_file 节点可以读取本地 txt、md、pdf、docx 文件。但默认权限是关闭的——这也是桌面端工具常见的安全策略。第一次用 read_file 节点它会弹一个授权请求询问是否允许访问这个文件。要点“允许”之后才能读取。如果你点错了“拒绝”后面在节点设置里可以重新打开权限列表手动添加允许目录。2.5 坑三启动白屏或加载超时如果你打开界面发现白屏先看任务管理器里是不是已经有一个 dsh-gui 进程在跑。这个工具单实例锁做的一般双击两次可能起两个进程后启动那个会白屏。杀掉所有 dsh-gui 进程再重新启动就好。另外如果本机 7860 端口被占用也会导致页面加载不出来这个在日志里会明确提示把端口占用解决即可。2.6 官方没写的小配置输出目录和日志级别配置里有两个选项我强烈建议你改一下output_dir所有写文件类节点的默认保存路径建议改成你自己的工作目录比如 D:/work/ai-output。log_level默认是 info调试工作流时改成 debug日志会详细记录每个节点的输入输出时间很多问题一眼就能看出来。改完配置文件记得重启 dsh-gui。3. 30 分钟实操从零搭一个“草稿文件 → 总结 → 周报”工作流3.1 先想清楚链路再动手画节点我搭的工作流很简单输入一个记录了一周零散想法的 Markdown 文件输出一份结构化的周报。拆成节点就是读文件、写提示词、调用模型、保存结果。如果之前在 Dify 上画过工作流你会发现这里的思路基本一样。DeepSeek Harness 的节点类型在 v0.2 里比较精简但核心这几个都有read_file、text_template、llm、write_file、text_splitter、http_request。对一个常见内容整理场景来说read_file→text_template→llm→write_file 已经够用。3.2 第一个节点读文件在画布上拖入一个 read_file 节点双击打开配置文件路径D:/work/notes.md编码UTF-8如果文件是其他编码会乱码后面会详说排查方式输出变量名file_content运行这个节点后file_content 变量就带着整个文件内容流到下一个节点。3.3 中间节点提示词模板 LLM拖入 text_template写模板你是周报助手。下面是一周的工作草稿请整理成周报包含三部分本周完成、问题与风险、下周计划。注意保留具体数字和结论不要编造。 草稿 {{ file_content }}模板里的变量用双花括号包裹跟常见模板引擎一致。然后拖入 llm 节点模型选择 DeepSeek把提示词模板的输出接进 llm 的 prompt 输入。参数我前面说了temperature 0.3max_tokens 1200。3.4 最后一个节点保存为 Markdown拖入 write_file 节点把它接到 llm 输出上配置保存路径D:/work/weekly.md内容模式覆盖写如果你希望保留历史可以把路径改成带日期变量的形式例如 weekly-{{ date }}.md这一步我放到第 5 章再讲。3.5 点运行看三步整个工作流跑完D:/work/weekly.md 就生成了。我建议别只看最终文件运行完依次点开三个节点看输出read_file 输出有没有读到全部内容、text_template 输出里的变量有没有正确填充、llm 输出是不是你想要的格式。这样即便出问题也能立刻定位到在哪一段断了。3.6 30 分钟其实大部分花在写提示词上工具本身的拖拽连线 5 分钟就能搞定真正花时间的是写模板。我第一版模板写得太笼统输出全是“该团队本周完成了一些工作”这种废话改成“保留具体数字和结论不要编造”之后才像能直接发出的周报。所以在搭工作流的时候别急着拖节点先在文本编辑器里把提示词打磨两遍再粘进 text_template。4. 实测结果与翻车现场乱码、超长文本、格式丢失的完整排查链路4.1 翻车一读取中文 Markdown 文件全乱码我第一次跑输出文件里全是乱码。当时第一反应是模型出问题了后来冷静下来一想模型收到的 prompt 就是乱的它再厉害也只能给你输出乱码。在 read_file 节点里看到 source_preview 也是乱的立刻意识到是文件编码不对。我的笔记文件是 Windows 记事本默认的 GBK/ANSI 编码而 read_file 节点默认按 UTF-8 解码。解决办法有两个一个是把笔记另存为 UTF-8另一个是 read_file 配置里加 encoding 参数写成 gb18030。我个人推荐前者毕竟之后所有节点都默认 UTF-8统一编码能省很多事。4.2 翻车二草稿太长直接超出上下文窗口第二版试跑文件里塞了我两个月的笔记大概 1 万多字。运行到 llm 节点日志里出现 context length exceeded节点状态标红。这是大模型应用最常见的错误之一原因就是输入文本太长超过了模型上下文限制。解决思路有三种加一个 text_splitter 节点把长文本切成若干段用 map-reduce 思路分块总结再合并。精简输入只截取最近一周的内容。在 llm 节点里把模型切到上下文更大的版本。我当时选的是先切分这是最通用的做法。text_splitter 节点按字符数或者段落数切块每块 2000 字左右然后让 LLM 对每一块先做摘要再用一个 merge_prompt 节点把多个摘要合并。工作流变成 read_file→splitter→llm(分块摘要)→merge_prompt→llm(合并)→write_file。逻辑上不复杂但链路长了排查也更需要有条理。4.3 翻车三模型输出好好的保存到文件格式却不对还有一次llm 节点输出预览里 Markdown 标题、列表都正常但保存到文件后全变成了纯文本换行和 # 号全没了。这个问题的根源不在模型而在 write_file 节点的配置。v0.2 的 write_file 默认把输入当作纯文本写入不处理任何 Markdown 语法。解决方式是在 write_file 节点里开启 Markdown 渲染支持或直接保持原样写入具体看你的需求。我踩过之后才明白最终输出文件的内容和 llm 预览不一致时优先检查输出节点而不是改提示词。4.4 排查思路永远先定位到具体节点再动手上面三个翻车案例虽然现象不同但排查思路是一样的从链路头端开始逐节点看输出。read_file 不对就看文件编码text_template 不对就看变量填充逻辑llm 不对就看参数和上下文长度write_file 不对就看写入配置。千万不要跳过中间节点直接怀疑模型那样会浪费大量时间。4.5 常见错误对照表现象可能原因解决方式输出乱码源文件编码与 read_file 默认编码不一致统一保存为 UTF-8或设置 encoding 参数全部节点变红日志报 context length exceeded输入文本超过模型上下文限制加 text_splitter 切块或换更大上下文模型llm 预览正常但文件格式丢失write_file 把内容当纯文本写入检查 write_file 配置确认是否开启 Markdown 支持节点正常但最终文件没有内容文件路径或写入权限有问题检查输出目录是否存在、是否有写权限提示词模板输出没填充变量变量名拼写或花括号层级不对对照模板输出内容确认变量名双花括号闭合5. 进阶模板化 命令行调用把工作流变成每天都能用的日常工具5.1 用变量把路径和日期通用化刚搭好的工作流只能处理固定文件 D:/work/notes.md可日常用法肯定不固定。v0.2 支持在配置里使用内置变量常用的有 {{date}}、{{user}}、{{input}}。把 read_file 的路径改成 D:/work/notes-{{date}}.md再把 write_file 的路径改成 D:/work/weekly-{{date}}.md这样每天新建一个笔记文件跑一次工作流就会自动生成对应的周报文件互不覆盖。5.2 用命令行把工作流变成“一键”在 dsh-gui 里搭好的工作流其实是以 .dshflow 文件形式保存的。它会默认存在配置目录的 workflows 文件夹里。在命令行里直接运行dsh run weekly.dshflow --set inputD:/work/today.md就可以不打开图形界面直接跑工作流。更进一步把这条命令做成 Windows 计划任务或者 macOS 的 cron每天下午 5 点自动跑一遍第二天早上群里就有周报了。5.3 工作流文件可以直接复制分享这也是我挺喜欢 v0.2 的一点工作流定义是一个本地文件没有绑定用户账号你把自己的 .dshflow 发给同事对方只要也装了 DeepSeek Harness改一下路径就能跑。如果团队里有人之前折腾过把 Dify 工作流转成工程代码的事就会知道这种本地文件式的定义后续做程序化处理要省心得多。5.4 别把工作流设计得太大一条链路最好只做一件事最后说一个我自己的体会。刚开始我把总结、翻译、润色、生成待办全部塞进一条工作流结果中间环节相互影响改一个节点连带崩好几个。后来拆成三条独立的工作流summary.dshflow 负责总结translate.dshflow 负责翻译weekly.dshflow 负责周报。每条链路短、目标单一出问题也容易修。搭这个工作流到现在我每天早上的动作变成把昨日记的草稿丢进 D:/work 目录双击一下 dsh 命令行五分钟不到就拿到整理好的内容。这种把 AI 从“网页对话框”变成“本地管道”的体验确实比一次次复制粘贴舒服很多。如果你的草稿整理、会议纪要、周报生成也有类似的重复劳动可以照这个思路先搭一条最小的链路跑通了再往上加节点。
