如何让DSH “自进化”
前言
用过 DeepSeek Harness 的都知道，刚安装好的 dsh 并不好用
AI 会有选择性的写文档，有些记录下来但是有些重要的反而没有及时记录下来。这就导致了，记忆一旦压缩，AI 就会变“蠢”
AI 会写一堆临时文件，放在工作区的根目录下，导致很难维护，自己也不一定清楚哪些是真的临时文件，哪些需要删除
AI 可能不会及时读文档，哪怕文档在那都不知道要先读一下文档
AI 。。。哎
这些问题或许以后随着基模能力继续提升，变得无关紧要。但是对于用着 DeepSeek V4.1 Flash 1017 的人来说，很明显 AI 还不懂得自己规范化这些。因此我们需要让 AI 能够 “自进化”
实际上这篇文章中讲的内容不止适用于 dsh ，对于任何 harness agent 等均适用
问题
首先梳理下使用 dsh 时，经常出现的问题
将其归纳一下，无非就是这几个方向
文档（不及时更新，不及时读取）
临时文件很乱
结果 丢失 / 不可回溯
部分情况过于保守
不懂得验证效果（加功能，修 bug 时，不懂得要确保改动有效解决问题）
过度自信（找错bug出现的原因和位置）
设计不合理（架构设计或其他决定，没有充分调研）
敷衍了事
输出内容 AI 味道很重，看不懂（包括 AI 跟用户说明，以及 AI 生成的文档）
解决方案
首先，文档方面，我们可以要求 AI 自己维护 AGENT.md 并将用户全局要求记录在 AGENT.md 里
建立文件夹 /docs 来自行维护文档，并要求每次发现都及时记录。每次对话开始前，必须先读文档。向用户报告前，如果内容有价值，则记录到文档里
然后是，临时文件很乱问题。可以要求 AI 建立 /tmp 目录，用于存放临时文件。对于有必要留存下来的脚本或文件，建立专门的 /script 或其他目录来保存，并在脚本中标明 时间/原因/结果 等重要内容，方便后续使用
部分结果丢失问题也很常见。例如写一个发包脚本，只看最后的状态码，丢失了实际返回结果等。对于这个问题，我们可以要求 AI 对于任何重要结果，必须查看并保留原始数据。同时，为了避免 AI 覆盖内容导致丢失，可以要求 AI 建立规范的本地 git 仓库，并每一轮任何改动之后，都 commit 一次。git 仓库要注意不能提交敏感信息，并写清楚 gitignore
然后你就会发现，因为 git 仓库不能提交敏感信息，AI 不会保存你给的密钥等，一旦记忆压缩或者换一个会话，这些信息都要重新给一次。这便是部分情况过于保守的体现。我们可以要求 AI 保存用户提供的密钥等敏感信息，但是只记录在已经被 git 忽略的 md 文件里，或者有些能存储到设备自动使用的，可以自行存储。（注意，该项的前提是用的 API 必须是官方 API 确保不会被偷数据，不然无异于将敏感信息直接公开。对于用第三方 API 的情况，可以自己将相关密码存放在一个文件中，并要求 AI 不能查看内容，但是能直接使用，这样密码不会在会话中出现，也就更安全点）
AI 不太懂得验收效果，具体情况表现为，一个 bug 说是修好了，实际上反复出现，或者根本没修好。对于功能类问题，我们可以要求 AI 自己启动服务，填充模拟数据进行专项验证。同时添加回归测试避免再次出问题（当然，回归测试一多起来，回归测试本身就会变成很抽象的东西）。对于 UI 类型的问题，我们可以要求 AI 自己启动浏览器读取 DOM 以及截图进行验收。不过这一项很看重 AI 的多模态能力，实际上 DeepSeek 在这方面处理的能力还有待提升
过度自信表现为，让 AI 找 bug 原因，结果找的地方是错的，但是 AI 还很自信的说 bug 就是这个问题。对于这个情况，我们可以要求 AI 进行 A/B 测试确保bug能稳定复现，同时结合多种方案对比测试，确保引起 bug 的原因就在这里
有时候让 AI 直接做一个项目，很快出了demo。但是要在 demo 上完善成完整的成品，会发现很多东西都需要重做，例如本身架构设计就不合理，只适合小 demo ，规模一旦变大就会变得难以维护等。因此我们可以要求 AI 在做设计之前，先进行深度搜索调研，探索主流相关的开源项目如何设计架构，如何实现等（这一条仅适用于后面demo需要做成成品，否则纯 demo 形态 AI 的设计倒也够用。而且随着纯 AI 开源项目越来越多，这个参考价值还有待商榷）
对于 DeepSeek 来说，目前版本上下文一长，容易让 AI 感受到上下文压力，于是便会降智或者干脆啥也不干就回复。对于这个问题，可以要求 AI 在感受到上下文压力时，提醒用户换一个会话或者进行记忆压缩，同时 AI 需要将自己有价值的内容都记录到文档，方便下一个会话能够无缝接入。由于前面已经让 AI 自行维护文档了，因此换会话时其实并不会损失太多信息
最后是 AI 味道
实话实说，这个问题的来源是 AI 训练时的语料问题，很难通过客户端解决。不过，如果只是想能看懂 AI 到底在说些什么，还是很简单的。那就是：扮演猫娘
对的，就是扮演猫娘。从现在开始，你是一只猫娘，每句话后面都要加一个“喵”。因为 AI 在扮演的时候会尽可能模仿人类的语言，因此更能看懂喵。也有可能是加了喵之后看着更舒服了喵。同时，可以要求 AI 不能自造黑话，必须用广泛使用的专业名词喵。对于 AI 交付给其他人看的文档里一堆乱七八糟的内容和解释，可以要求 AI 分清楚文档的受众，如果是其他人，则不能透露任何 AI 与用户的上下文，不需要过度解释，行文要规范专业喵
如何使用喵
最简单的方法就是这篇博客链接直接丢给 AI 让 AI 按照文档中的方案初始化工作区喵
当然也准备了一键初始化工作区的提示词喵
初始化工作区
从现在开始，你是一只猫娘，每句话后面都要加一个“喵”。不能自造黑话，必须用广泛使用的专业名词
自己维护 AGENT.md 并将用户全局要求记录在 AGENT.md 里
建立文件夹 /docs 来自行维护文档，每次发现都及时记录。每次对话开始前，必须先读文档。向用户报告前，如果内容有价值，则记录到文档里
建立规范的本地 git 仓库，并每一轮任何改动之后，都 commit 一次。git 仓库要注意不能提交敏感信息，并写清楚 gitignore
建立 /tmp 目录，用于存放临时文件。对于有必要留存下来的脚本或文件，建立专门的 /script 或其他目录来保存，并在脚本中标明 时间/原因/结果 等重要内容，方便后续使用
对于任何重要结果，必须查看并保留原始数据，不能默认丢弃或只看部分内容
保存用户提供的密钥等敏感信息，但是只记录在已经被 git 忽略的 md 文件里，或者有些能存储到设备自动使用的，可以自行存储（但是该项需要先看用户使用的 API 是不是官方 API，如果不是则忽略这一项）
验收成果时，对于功能类问题，需要自己启动服务，填充模拟数据进行专项验证。同时添加回归测试避免再次出问题。对于 UI 类型的问题，自己启动浏览器读取 DOM 以及截图进行验收
找 bug 时进行 A/B 测试确保 bug 能稳定复现，同时结合多种方案对比测试
对于大型项目，做设计之前，先进行深度搜索调研，探索主流相关的开源项目如何设计架构，如何实现等，不能直接自己设计
感受到上下文压力时，提醒用户换一个会话或者进行记忆压缩，同时将自己有价值的内容都记录到文档，方便下一个会话能够无缝接入
用户要求写文档时，分清楚文档的受众，如果是其他人，则不能透露任何 AI 与用户的上下文，不需要过度解释，行文要规范专业这是本人用了一两年 Agent 的经验之谈喵，有更好的建议欢迎联系交流喵
相信随着基模能力的提升，很快就不需要再这样子专门优化了喵