希望增加无需指定项目即可使用的临时聊天功能

[askdkc]

目前 DSH 必须先指定一个项目，才能开始与 AI 进行聊天。

但是在实际使用中，有时只是想进行简单的资料调查、技术问题咨询，或者临时与 AI 讨论某个话题，并不一定属于某个具体项目。

因此，希望能够增加一个用于临时聊天的入口，例如 Temporary Chat / 临时聊天。

理想情况下，这类聊天应当：

• 无需创建或指定项目即可直接开始；
• 适合简单调查、技术咨询和临时讨论；
• 不需要与现有项目结构绑定；
• 如果用户之后有需要，可以再将聊天内容保存或移动到某个项目中。

这样可以降低开始一次简单 AI 对话的操作成本，也能避免为了临时调查而创建大量没有实际意义的项目。

我认为，这会让 DSH 在日常使用中的体验更加自然。

---

2026/9/7 Update

After some discussion here, I decided to just build a plugin and see how it works in practice.

If anyone is interested, here is the repository:

https://github.com/askdkc/dsh-chat

So far, it works pretty much the way I expected.

The screenshots are in Japanese simply because I'm Japanese, so please don't read too much into that.
Also, for some reason, GLM-5.3 Flash hallucinated and decided to call me “Verticon.” 😂

---

在这里以及其他地方讨论了一些之后，我决定干脆自己做一个插件，先实际试试看效果。

如果有人感兴趣，这是仓库地址：

https://github.com/askdkc/dsh-chat

目前来看，它基本上就是按照我预期的方式在工作。

截图里是日语，只是因为我是日本人，所以不用太在意。
顺便一提，不知道为什么，GLM-5.3 Flash 出现了幻觉，莫名其妙地把我叫成了“Verticon”。😂

[2455DD]

这种情况下为什么不用Web端服务或者其他面向Chat应用的软件？

[askdkc]

You can say that.
But why not is my point.
Every fucking coding tool can do this kind of simple thing but DSH can't?
それが悲しい。

[2455DD]

Kinda make sense. But as far as I know, when you are using some tui-based agent tools, taking claude code as an example, your current working directory is your "Project". So you are having a context-ed conversation in a certain project, not a "temporary chat". In DSH, as it basically works as a webui app( in a default profile), it doesn't have this implicit function. Maybe you can seek a sidebar plugin to do that.

[askdkc]

ChatGPT/Codex desktop app which
does both.
Again my point is why not? DSH should have done better.

何故ベストを尽くさないのか。

[aaronlei]

哥们，你建个空目录就行了。

[askdkc]

因为你的“需求分析”从一开始就把我没有提出的前提加进去了。

“不想手动选择工作区”并不等于“希望软件自动选择一个工作区”。

还有第三种情况：这个会话根本不需要工作区。

我说的从一开始就是这个。

[Dave-12138]

因为你的“需求分析”从一开始就把我没有提出的前提加进去了。

“不想手动选择工作区”并不等于“希望软件自动选择一个工作区”。

还有第三种情况：这个会话根本不需要工作区。

我说的从一开始就是这个。

那Harness本就不适配你的需求，你需要的是专门用来聊天的客户端。

如果你坚持认为Harness就该这样，因为 ChatGPT 和 Claude Desktop 都是这样的。。。那你可能有点误解，这俩本来都只是聊天客户端，Agents是后来强行捆绑进去的，本来是分开成两个软件的。

[askdkc]

这里讨论的是用户需要什么功能，而不是你为了证明自己观点正确，把 ChatGPT 和 Claude 过去的产品历史搬出来当论据。

它们以前是不是分成两个软件，和用户现在希望 DSH 提供什么功能，到底有什么关系？

而且你也没有证明 DSH 在本质上就是一种完全不同、因此不能提供普通聊天窗口的产品。

说到底，DSH 也是调用模型 API，再把 Harness 提供的工具、上下文和能力连接给模型。既然如此，一个“不绑定工作区、不加载项目工具，只进行普通对话”的会话，到底在架构上有什么不可实现的地方？

如果只是因为“这是 Harness，不是聊天客户端”这种标签，就拒绝一个技术上如此简单、而且用户明确需要的功能，那听起来不像是在做需求分析，更像是在为了维护既有观点，不断给“不想实现”找理由。

用户提出一个简单功能，你们却不断拿产品历史、分类和定义来证明“这个需求不该存在”，这到底是在解决用户的问题，还是在和用户争论谁的定义才是正确的？

[Dave-12138]

它们以前是不是分成两个软件，和用户现在希望 DSH 提供什么功能，到底有什么关系？

而且你也没有证明 DSH 在本质上就是一种完全不同、因此不能提供普通聊天窗口的产品。

因为你话里话外有点将这俩当规范了，什么Harness都得像这俩从聊天软件发展来的看齐。

对于它们来说，日常聊天才是它们的本职工作；而对于DSH来说，“那为啥不用网页端和移动端”。

软件提供什么功能取决于它是为解决什么需求而生的，我不认为这有任何难以理解的地方。

如果先有个DeepSeek Desktop，然后有了DeepSeek Harness，又因为Desktop用户更多，将Harness塞进Desktop从而抢Agents市场的新用户，那你确实可以看到你想要的捆绑包。

但很遗憾没有，移动端APP才是中国市场想要的，或者说DeepSeek选择的答案，不同发展轨迹自会有不同结果。

微软商店那个安卓APP靠应用宝上PC可能都没多少人听说过，没有Desktop只有移动端APP、PC用网页端就是设计结果

至于”本质不同“。。。你是否记得 Claude Code？把Claude Code和Claude Desktop一起摆出来会有多少人认为只有前者是harness?

说到底，DSH 也是调用模型 API，再把 Harness 提供的工具、上下文和能力连接给模型。既然如此，一个“不绑定工作区、不加载项目工具，只进行普通对话”的会话，到底在架构上有什么不可实现的地方？

如果只是因为“这是 Harness，不是聊天客户端”这种标签，就拒绝一个技术上如此简单、而且用户明确需要的功能，那听起来不像是在做需求分析，更像是在为了维护既有观点，不断给“不想实现”找理由。

用户提出一个简单功能，你们却不断拿产品历史、分类和定义来证明“这个需求不该存在”，这到底是在解决用户的问题，还是在和用户争论谁的定义才是正确的？

“用户需要”本身就很……诡异，用户知道自己需要聊天客户端的功能不找聊天客户端，找个启动就麻烦很多的 Harness吗？那或许应该假定如!此!强!劲!的用户自己有能解决这个问题的能力，比如直接雷霆大解耦写个无上下文注入的聊天侧栏什么的插件，运气好的话社区里说不定已经自己长出来了。

简单、并非不可实现……雷霆大解耦确实简单，但你需要和本体组起来管理Session。改改注册链路以便掐掉注入、微调一下配置结构、调一下UI，再施点系统提示词变了却不会缓存爆炸的魔法……嗯，比写个新项目那确实还算简单

假设就把这个“简单功能”塞进去了。但接下来呢？要让它读写文件吗？允许的话安全护栏怎么定？要给它用skills、AGENTS.md吗？skills都加了，那mcp呢？这些内容从Harness的部分共享还是独立管理？独立的话会不会让用户感到混乱？不独立的话会不会让上下文误导llm？要加助手预设吗？上下文编辑是不是也要加？

产品定位与后续迭代的问题当然会来的，除非真就还是解耦大道至简把网页聊天设计放进来，在界面顶上放两个DeepSeek Harness DeepSeek Chat页签来回切换，那很省事了。

...你们却不断拿产品历史、分类和定义来证明“这个需求不该存在” ... 在和用户争论谁的定义才是正确的？

ber，我看起来很像官方人员吗？你是否清醒。。。

不太理解你为何认为一直有人跟你争论需求该不该存在不是解决问题，但很遗憾，问题在于捆绑软件让你对Harness有奇怪的预期。

而我，我只是恰巧有这样的需求：DeepSeek Harness 就该好好做Harness，日常对话应该用更适用于日常对话的软件。给不是这个定位的软件强行加相关功能只是在浪费UI的预留空位和我的硬盘，占了位还受限于软件自身只能端上来没有跨端同步还难以操控上下文的幽默玩意。

希望你不是带着「你希望加就是用户的需求，我不希望加就是捂嘴应该开除用户籍」的想法参与讨论。。。这反手转进我有种二游节奏圈的熟悉感，直接给我PTSD干出来了。。。

[askdkc]

你这次终于开始讨论真正有意义的技术问题了：Session 管理、context injection、skills、MCP、文件权限、UI 边界，这些确实都是实现时需要考虑的事情。

但这些只能说明“这个功能需要设计”，不能证明“这个需求不该存在”。

而且更有意思的是，这个 Discussion 下面已经有其他用户实际遇到了类似问题：禁用 directory picker 之后，因为没有 workspace 连 session 都无法创建，最后只能写插件建立默认 workspace，甚至明确提出希望 workspace 和 directory 解耦。

所以这显然不只是我一个人“对 Harness 有奇怪期待”。

我提出的是一个功能需求。你不想要这个功能，也完全可以。

但“我不需要”与“这个需求不合理”，仍然是两件不同的事情。

[sandersyao]

某种意义上我也算碰到这个问题，我在研究如何分布式部署 dsh 的时候特意将目录选择器禁用：

- id: directory-picker
  disabled: true

结果流程就锁在一个没有工作区无法创建会话的场景里。

我采用了折中的方式进行解决：写一个插件专门用来建立“默认工作区”

https://github.com/sandersyao/dsh-workspace-bootstrap

我还不太清楚 dsh 团队对工作区之后有没有其他相关设计，毕竟现在只是 pre-release 阶段。

目前来看，我可能更希望能让工作区和目录解耦。

[YesSanSan]

工作区是必须的，否则很多工具都会出现问题，比如shell工具需要一个工作目录。
如果没有工作区，执行pwd应该看到什么结果？写入./result.md这个文件会创建在哪里？如果不做处理，全部抛错误，harness的性能直接废掉一大半。
更好的方法是自动创建临时目录作为工作区，但UI上显示为无工作区，即不需要手动选择工作区，用户体验是完全一致的。
可以试试 https://github.com/wjj-8283/dsh-temp-workspace，它理论上恰好能解决这个问题，但我还没用过这个插件。

[Diluka]

一定有工作区的，ChatGPT和VSCode copilot的无工作目录模式其实是在自己的临时目录里面运行的。你直接把会话开到/tmp/temp-chat上面设置仅工作区读写或者只读就行了。

[Wuzk-97]

需要は合理的だが、理論的には無理がある。実装としては、テンポラリディレクトリで自動的にワークスペースを作成する形になるはずだ。ワークスペースはこの種のIDEの基盤であり、関わる範囲が広すぎる。最終的に言えるのは、dshチームのdshに対する構想は、これらを自分たちで開発することではないだろうということだ。こういう需要は山ほどある。「万物をプラグイン化」というコンセプトを持ち込んだ時点で、このプロジェクトの理想的な姿は、プラグインで自分専用のエージェントを構築することになる。

[hytime]

可以自己搓一个插件，聊天让其只存在于~/.dsh/chat/session 中，很多桌面端其实差不多是这种思路的……

[askdkc]

这其实就是我上面贴的 dsh-chat 已经在做的事情……
每个普通聊天都会自动使用 ~/.dsh/ 下独立的工作目录，用户不需要选择项目。
所以你现在提出的方案，基本上就是这个插件的实现方式。