8 篇博文 含有标签「工程实践」

截至2026年8月15日，Oh-My-DSH目录已收录精选插件 1117个，监测生态仓库 1521个，累计获得Star 301295 颗。

今天这篇文章，我就从众多插件里，挑出10个最值得装的，希望对你会有所帮助。

一、先搞懂Harness的插件怎么装​

在聊具体插件之前，我们先花2分钟搞清楚怎么装插件。

Harness的插件安装只有一条命令：

dsh plugin --profile web add "github:owner/repo#ref"

比如装一个视觉插件：

dsh plugin --profile web add "github:liustack/modlens#main"

这条命令会从GitHub拉取插件代码，通过dsh.bundle声明自动启用它。安装完成后，重启dsh web服务并刷新页面，插件就生效了。

一个重要的坑：启动Web UI时必须加上--patch参数，否则很多插件和技能不会生效。完整命令：

npx @deepseek-ai/dsh web --patch

另外，官方建议插件仓库打上#dsh标签，这样社区目录才能自动收录。想找更多插件，可以直接在GitHub搜索dsh-plugin话题。

下面开始正式推荐。

二、插件1：ModLens​

它给纯文本模型装上一双眼睛。

仓库：liustack/modlens | Star：905+

DeepSeek本身是纯文本模型，最大的短板就是看不了图。你贴一张报错截图、丢一个UI设计稿，它只能对着文字干瞪眼。

ModLens的README第一句就是"Give a text-only model sight"。

装上之后，图片可以直接粘贴进聊天框，它通过一个原生的modlens_read_image工具，把图转成结构化文本证据，再喂给DeepSeek作答。

核心思路是：DeepSeek还是那个纯文本模型，但凭空多了双眼睛。视觉模型把图像内容"翻译"成文字，纯文本模型再接着处理——就像请了个会看图的朋友在旁边给你念。

安装命令（注意必须锁版本号，别用@latest）：

dsh plugin --profile web add "@liustack/modlens@3.17.2"

场景：贴报错截图让AI分析、丢UI设计稿让AI还原、识别流程图中的文字信息。

三、插件2：dsh-web-ui​

它从毛坯到精装，一站式全家桶。

仓库：zhu1090093659/dsh-web-ui | Star：1013+

如果只让装一个插件，我会选dsh-web-ui。

默认的dsh web界面就是个纯聊天框，用久了你会觉得它"太素了"。

装上这个插件集之后直接变精装房——任务看板、Git图谱、右侧面板、移动端UI、宠物、实时Token统计、皮肤中心，一套全给齐。

最让我惊喜的是任务看板（dsh-task-board）：五列看板——待规划/待办/进行中/已完成/已失败。卡片能直接交给真实DSH会话去执行，跑完自动更新状态，还支持cron定时任务。

安装命令：

dsh plugin --profile web add "github:zhu1090093659/dsh-web-ui#main"

装完之后，左侧边栏多了任务看板、Git图谱、Token统计等面板，整个界面从"毛坯"变成了"精装"。

场景：所有场景。这是Harness的"基础设施级"插件，装了不亏。

四、插件3：dsh-better-sidebar​

它把WebUI变成Codex风格的工作台。

仓库：omdsh-dev/DSH-better-sidebar | Star：684+

如果你习惯用Codex或Claude Code的界面风格，dsh-better-sidebar就是给你准备的。

这个插件给Harness的WebUI加了一个侧边栏工作台，支持文件查看/编辑、终端、Git、子代理，还有可扩展的Tab。

装完之后，整个界面跟Codex几乎一模一样。

安装命令：

dsh plugin --profile web add "github:omdsh-dev/DSH-better-sidebar#main"

dsh-better-sidebar vs dsh-web-ui：前者更像一个完整的工作台布局，侧重文件树、终端、Git这些开发工具；后者更像一个功能集合包，侧重任务看板、皮肤、宠物这些增强功能。

两个可以一起装，互不冲突——better-sidebar管布局，web-ui管功能。

场景：习惯IDE风格界面的开发者，想在浏览器里获得类似Codex的体验。

五、插件4：dsh-TUI​

它把Harness搬回终端。

仓库：ccch1mneyyy/dsh-TUI | Star：793+

这是dsh中最火的插件之一。

官方没有推出任何CLI或TUI形式，所以TUI只能通过插件来扩展。

装上之后执行：

dsh --profile cc-tui

就可以进入DeepSeek Harness的全屏终端界面了。常用的命令基本都涵盖了。

dsh-TUI vs dsh-better-sidebar：better-sidebar是给WebUI补一个工作台，dsh-TUI则是直接把整个交互搬回终端。

平时习惯在浏览器里看文件树、预览Markdown，就装better-sidebar；已经在日常离不开Claude Code、Codex CLI这种风格的，就装dsh-TUI。

安装命令：

dsh plugin --profile web add "github:ccch1mneyyy/dsh-TUI#main"

场景：终端爱好者、习惯CLI工作流的开发者、想在远程服务器上跑Harness的场景。

六、插件5：deepseek-harness-desktop​

它把Harness变成桌面App。

仓库：anywhere-labs/deepseek-harness-desktop | Star：4745+

这是最近最火的Harness插件之一。

官方没有提供桌面端，社区把这个缺口补上了。

核心功能：把DeepSeek Harness打包成Electron桌面应用，自动启动和管理本地Harness服务，集成系统托盘+桌面窗口。

最爽的一点是：无需装Node.js、无需敲命令。双击图标就能跑起来。

注意：这是社区项目，不是DeepSeek官方桌面端。目前主要支持macOS和Windows。插件市场、手机远程这些能力还在后续规划里。

安装方式：直接去GitHub Releases下载对应平台的安装包，双击安装即可。

场景：不想装Node.js、不想敲命令的开发者，或者想在系统托盘里随时启动Harness的用户。

七、插件6：dsh-at-file​

它让引用文件，像Codex一样丝滑。

仓库：omdsh-dev/dsh-at-file

这是我在Codex中见过的功能——通过@的方式引用文件。

装上之后，在对话输入框中输入@，会自动弹出工作区文件列表供你选择，选中的文件内容会自动附加到提示词中。

不用再手动复制粘贴文件内容了。

安装命令：

dsh plugin --profile web add "github:omdsh-dev/dsh-at-file#main"

场景：需要频繁引用项目文件进行对话的场景。

装了之后，Harness在文件引用这个体验上就追平了Codex。

八、插件7：dsh-agent-teams​

它能让多智能体团队协作。

仓库：NanmiCoder/dsh-agent-teams

安装这个插件后，任何会话只需一句自然语言（例如"用AgentTeams调研一下XX"），即可驱动一个多智能体团队协作完成目标，并在Web GUI右上角实时看到团队活动面板。

工作流程：创建团队（队长=当前会话Agent）→拉成员（可续聊子代理）→拆任务并声明依赖→成员间直接收发消息（邮箱直达+唤醒，无队长中转）。

安装命令：

dsh plugin --profile web add "github:dsh-external/dsh-agent-teams#main"

注意：本仓库不公开，github:安装依赖本机git对dsh-external/dsh-agent-teams的读取权限。

场景：需要多Agent协作的复杂任务，比如市场调研、技术选型分析、多维度报告生成。

九、插件8：dsh-plan-execute​

它能让双模型路由，规划和执行分离。

仓库：dsh-external/dsh-plan-execute

这个插件的思路非常聪明：规划用推理模型，执行用经济模型。

复杂任务先让推理模型做规划和拆解，生成的子任务再交给经济模型去执行。

规划阶段的思考质量高，执行阶段的成本低——脑子和手脚分开用。

安装命令：

dsh plugin --profile web add "github:dsh-external/dsh-plan-execute#main"

装完之后，Web设置页会多出"规划/执行模型"的配置行。

场景：复杂任务需要高质量规划，但不想让执行过程烧太多Token。

这是"降本增效"的典型插件。

十、插件9：dsh-context-doctor​

它让你看清模型的"上下文账单"。

仓库：Zhenyu98/dsh-context-doctor

很多人不知道，大模型每次请求背着多少上下文——系统提示词、技能目录、工具schema全部累加在一起，每一轮都在烧Token。

dsh-context-doctor让你看清这笔账单。它逐项量化指令链/技能目录/工具schema的Token成本，自动检测重复与冲突，给出可执行裁剪建议。

Web端提供圆环面板可视化展示，同时提供context_audit工具供Agent调用。全程只读，不影响任何配置。

安装命令：

dsh plugin --profile web add "github:Zhenyu98/dsh-context-doctor#main"

场景：Token消耗异常的排查、Agent上下文优化、成本敏感型项目的精细化管理。

十一、插件10：dsh-reverse-skill​

它里面包含85个安全研究技能包。

仓库：dhicoc/dsh-reverse-skill

一个包含了85个SKILL.md的技能路由包，覆盖逆向工程、授权渗透测试与安全研究等领域。

如果你在做安全相关的工作，这个插件能让你快速获得一整套方法论和工具链。

安装命令：

dsh plugin --profile web add "github:dhicoc/dsh-reverse-skill#main"

场景：安全研究、代码审计、逆向工程、渗透测试。

十二、优缺点​

优点​

1. 极致可定制：从毛坯到精装，全部自己决定。不像其他工具那样"给你什么用什么"。
2. 生态爆炸式增长：1117个插件，1521个生态仓库，301295颗Star。你要的功能大概率已经有了。
3. 安装极其简单：一条dsh plugin --profile web add命令搞定一切。不需要手动下载、解压、配置。
4. 开源协议友好：MIT协议，可自由使用、修改、商用。

缺点​

1. 版本波动大：目前还是developer preview，插件迭代很快，装之前记得看版本。
2. 部分插件需要额外配置：比如ModLens需要锁版本号，dsh-agent-teams需要Git权限。
3. 启动时记得加--patch：否则技能和部分插件不生效。

选装建议​

十三、写在最后​

回到最初的问题：DeepSeek Harness必装的10个插件是什么？

我给它们分了三个层次：

第一层（核心体验层）：dsh-web-ui和dsh-better-sidebar。这两个是Harness的"精装修"，装了之后界面体验直接从"毛坯"变"精装"。

第二层（交互方式层）：dsh-TUI（终端）、deepseek-harness-desktop（桌面App）、dsh-at-file（@引用文件）。这三个决定了你用什么方式跟Harness交互。

第三层（能力扩展层）：ModLens（看图）、dsh-agent-teams（多Agent）、dsh-plan-execute（双模型）、dsh-context-doctor（上下文审计）、dsh-reverse-skill（安全技能）。这些按需加载，需要什么能力就装什么插件。

DeepSeek给Harness的口号是"一切皆插件"。

从这一千多个插件来看，这真的不是口号——模型、工具、技能、会话、沙箱、存储、循环、调度、UI，全都可以拆下来换掉。

我的建议是：先装dsh-web-ui和dsh-at-file这两个最基础的，把Harness从"毛坯"变成"能住"。然后根据你的使用习惯，选一个交互方式（TUI或桌面App）。最后遇到具体需求的时候（比如要看图、要多Agent协作），再去GitHub搜索dsh-plugin话题找对应的插件装上。

一千多个插件，总有一款适合你。

开源地址​

• DeepSeek Harness官方仓库：https://github.com/deepseek-ai/deepseek-harness（11万+ Star）
• Oh-My-DSH插件聚合社区：https://github.com/like-study1/Oh-My-DSH（1117个插件）
• Awesome DSH Plugin精选列表：https://github.com/awesome-dsh-plugin/awesome-dsh-plugin（218个插件）

🛠️ 工具分享 | 2026-09-03

使用方式：把这篇文档丢给你电脑的 Agent（Codex、Claude 或其他），让 AI 帮你配置。

推荐 Skill​

在 AI 市场安装 ept-dsh Skill：

https://ai-market.chehejia.com/?page=skills&skill=vfmxzgyvvqvtm5mmvf4j&creatorUid=18211132604_64538&rankType=hot&pageSize=20

⚠️ 注意：这个 Skill 不是接入融合云网关，而是调用你自己的 EPT LLM API（EPT Codex Responses API / EPT Claude Anthropic API）。每次对话都从你自己的 EPT 额度中扣除，占用的是个人 EPT 用量，与融合云 Token 额度无关。想用公司融合云额度，请参考《DeepSeek Harness 接入融合云模型指南》。

效果​

• 在 DSH 中使用 EPT 模型（如 baidu-deepseek-v4-flash）
• 一键启动 / 停止 / 查看 DSH Web（端口 3080）
• 一键启动 / 停止 / 测试 EPT Claude 本地代理（127.0.0.1:8787）
• 一键把 EPT Codex Key 刷新进 DSH 凭据

前置条件​

• 已安装 DeepSeek Harness，~/.dsh 目录存在
• 已登录 EPT，~/.config/ept/auth_session.json 存在且含 portal_token
• 电脑已安装 Codex 或 Claude 客户端，可安装 Skill

第一步：安装 Skill​

打开上面的 AI 市场链接安装 ept-dsh。安装后直接对你的 Agent 说「使用 ept-dsh 启动 DSH」即可。

第二步：配置 settings.yaml​

编辑 ~/.dsh/settings.yaml，在末尾追加 provider 配置。

走 EPT Claude（需要本机代理）：

llm-pi-ai:
  providers:
    ept-claude:
      displayName: EPT Claude (Anthropic)
      apiKeyEnv: EPT_CLAUDE_AUTH_TOKEN
      api: anthropic-messages
      baseURL: http://127.0.0.1:8787
      models:
        - id: baidu-deepseek-v4-flash
          name: baidu-deepseek-v4-flash

走 EPT Codex（直连，无需代理）：

llm-pi-ai:
  providers:
    ept-copilot:
      displayName: EPT Codex
      apiKeyEnv: EPT_CODEX_API_KEY
      api: openai-responses
      baseURL: https://portal-k8s-prod.ep.chehejia.com/api/copilot/codex/v1
      models:
        - id: baidu-deepseek-v4-flash
          name: baidu-deepseek-v4-flash

模型 id 以 EPT 实际提供的为准；/models 接口 404 不代表 provider 不可用，直接用已知模型 id 即可。

第三步：启动 EPT Claude 代理（仅 ept-claude 需要）​

EPT Claude 要求 Authorization: Bearer，而 Anthropic SDK 默认发 x-api-key，所以 Skill 内置了本机代理做转换。把 <skill-root> 换成 Skill 实际安装路径（如 ~/.agents/skills/ept-dsh）：

python "<skill-root>\scripts\start_ept_claude_proxy.py"
python "<skill-root>\scripts\test_ept_claude_proxy.py"

代理只监听 127.0.0.1:8787；每次请求实时读取 EPT 登录态，登录态刷新后无需重启代理。

第四步：填入 / 刷新凭据​

• EPT Claude：~/.dsh/.credentials.yaml 中添加 EPT_CLAUDE_AUTH_TOKEN。代理会忽略这个值，改用 EPT 当前 portal_token，所以填非空占位符即可。
• EPT Codex：EPT 登录态刷新后，在同一 PowerShell 会话确认 EPT_CODEX_API_KEY 环境变量已存在，然后执行：

python "<skill-root>\scripts\refresh_ept_key.py"

该脚本只更新 refs.EPT_CODEX_API_KEY，保留其他凭据，并自动生成 .bak-时间戳 备份。更新后重启 DSH Web。

第五步：启动 DSH​

# npx 方式（推荐）
python "<skill-root>\scripts\start_dsh.py" --npx

# 源码方式
python "<skill-root>\scripts\start_dsh.py" --source --source-path "<dsh源码目录>"

# 查看 / 停止
python "<skill-root>\scripts\start_dsh.py" --status
python "<skill-root>\scripts\start_dsh.py" --stop

必须使用 DSH 输出的完整 ?token=... 地址，不能只打开裸地址；同一时间只启动一个 3080 实例。

验证​

python "<skill-root>\scripts\start_ept_claude_proxy.py" --status
python "<skill-root>\scripts\test_ept_claude_proxy.py"
python "<skill-root>\scripts\start_dsh.py" --status

代理测试通过会输出 EPT Claude proxy 通过：HTTP 200。

关键参数说明​

回滚​

# 恢复备份（refresh 脚本自动生成）
Copy-Item "$env:USERPROFILE\.dsh\.credentials.yaml.bak-时间戳" "$env:USERPROFILE\.dsh\.credentials.yaml" -Force

删除 settings.yaml 中的 ept-claude / ept-copilot provider 节即可回到原状。

常见问题​

Q: 看不到 EPT 模型？ 检查 settings.yaml 缩进、凭据 ref 是否匹配、代理是否已启动。

Q: Claude 401 / 403？ 先运行 test_ept_claude_proxy.py；失败则重新执行 EPT 登录或 ept claude，不要改 DSH 源码。

Q: 代理或 DSH 端口冲突？ 先 --stop，再启动一个实例。

Q: 浏览器打开 401？ 使用完整 ?token=... URL。

Q: 用这个 Skill 会扣费吗？ 会。它调用的是你自己的 EPT LLM API，所有请求从个人 EPT 额度中扣除；如需使用公司融合云额度，请改用融合云网关方案。

使用公司 EPT 模型时，保留凭据在 $env:USERPROFILE\.dsh\.credentials.yaml，不得打印 key、token、凭据内容、请求体或 Authorization 头。

路线选择​

• ept-copilot：EPT Codex Responses API，直连 https://portal-k8s-prod.ep.chehejia.com/api/copilot/codex/v1，api: openai-responses，凭据引用 EPT_CODEX_API_KEY。
• ept-claude：EPT Claude Anthropic API。必须经本 Skill 的本机代理，api: anthropic-messages，baseURL: http://127.0.0.1:8787，凭据引用可保留为 EPT_CLAUDE_AUTH_TOKEN。

不要修改 DeepSeek Harness 源码来适配 EPT Claude。Anthropic SDK 默认发 x-api-key，而 EPT Claude 要求 Authorization: Bearer；本机代理负责转换。

Claude 代理​

先启动并确认代理，再启动 DSH：

python "<skill-root>\scripts\start_ept_claude_proxy.py"
python "<skill-root>\scripts\start_ept_claude_proxy.py" --status
python "<skill-root>\scripts\test_ept_claude_proxy.py"

代理只监听 127.0.0.1:8787。每次请求读取 %USERPROFILE%\.config\ept\auth_session.json 的 portal_token，所以 EPT 登录态刷新后无需重启代理。代理不记录 prompt 或 token。

在 $env:USERPROFILE\.dsh\settings.yaml 中保留或添加：

llm-pi-ai:
  providers:
    ept-claude:
      displayName: EPT Claude (Anthropic)
      apiKeyEnv: EPT_CLAUDE_AUTH_TOKEN
      api: anthropic-messages
      baseURL: http://127.0.0.1:8787
      models:
        - id: baidu-deepseek-v4-flash
          name: baidu-deepseek-v4-flash

EPT_CLAUDE_AUTH_TOKEN 只需是非空凭据；代理会丢弃 DSH 传来的 key，改用 EPT 当前 portal_token。缺少该 ref 时，把一个非敏感占位值保存为该 ref，或同步当前 EPT token。

启动 DSH​

优先使用内置脚本；同一时间只启动一个 3080 Web 实例：

python "<skill-root>\scripts\start_dsh.py" --npx
python "<skill-root>\scripts\start_dsh.py" --source --source-path "<dsh-source>"
python "<skill-root>\scripts\start_dsh.py" --status
python "<skill-root>\scripts\start_dsh.py" --stop

npx 命令：

$env:DSH_HOME = Join-Path $env:USERPROFILE '.dsh'
npx --yes --package '@deepseek-ai/dsh@alpha' dsh web --no-open

源码命令必须在 DSH 仓库执行：

$env:DSH_HOME = Join-Path $env:USERPROFILE '.dsh'
pnpm dsh web --no-open

始终使用 DSH 输出的完整 ?token=... URL，不能只打开裸地址。

刷新 EPT Codex key​

在 EPT 登录态已刷新、且当前 PowerShell 拿到 EPT_CODEX_API_KEY 后执行：

python "<skill-root>\scripts\refresh_ept_key.py"

代理认证会读取 %USERPROFILE%\.config\ept\auth_session.json；也可通过环境变量 EPT_AUTH_SESSION 指定该文件路径。刷新脚本读取环境变量 EPT_CODEX_API_KEY。

该脚本只更新 refs.EPT_CODEX_API_KEY，保留 EPT_CLAUDE_AUTH_TOKEN、CHJ_GATEWAY_API_KEY 和 records。更新后重启 DSH Web。

排查​

• Claude 401/403：先运行 python scripts/test_ept_claude_proxy.py。失败时让用户重新执行 EPT 登录或 ept claude；不要改 DSH 源码。
• Claude 代理端口冲突：python scripts/start_ept_claude_proxy.py --stop 后重启。
• DSH Web 端口冲突：python scripts/start_dsh.py --stop 后只启动一个实例。
• 浏览器 401：使用包含 token 的完整 URL。
• EPT /models 404：不是 provider 不可用的证据；使用已知模型 id。
• Codex 401/403：刷新 EPT_CODEX_API_KEY，运行刷新脚本，然后重启 DSH。

目标：把公司内部 LLM 接口接进 DeepSeek Harness 直接用。 结论：主路线（chj-gateway / deepseek-v4）已经在用；本目录补全模型清单，并新增 EPT Copilot（GPT-5.6，Responses API） 作为第二 provider（路线 C）。

一、现状盘点（已侦察确凿）​

▲ 完整模型清单请在本机连 VPN 后用 verify.ps1 拉取（网关 /v1/models）。

二、一句话的 EPT 机制解析​

ept codex 做的事：用 auth_session 登录态 → 从企业 copilot 拉取配置 → 通过环境变量注入 base_url + API key（EPT_CODEX_API_KEY）→ 启动 Codex，Codex 走 .../api/copilot/codex/v1/responses。 也就是说公司 LLM 的“钥匙”是 portal 域名的 Bearer 令牌（auth_session.json 里的 access_token / portal_token 二选一，见 verify.ps1 探测结果）。

三、目录文件​

dsh-ept-integration/
├── README.md             # 本文件
├── provider-merge.yml    # 两个 provider 的配置片段（合并目标）
├── verify.ps1            # ① VPN 终端先跑：拉 chj 模型 + 探测 ept 可用令牌
├── apply.ps1             # ② 备份+安全合并进 $DSH_HOME/settings.yaml
└── refresh-ept-key.ps1   # ③ （可选）刷新/写入 ept 令牌到 credentials

四、操作步骤​

第 1 步（重要）：先探测，别急着改​

在你的正常终端（已连公司 VPN）里跑：

powershell -ExecutionPolicy Bypass -File D:\bowen\git-project\dsh-ept-integration\verify.ps1

它会（只读，绝不打印密钥值）：

1. 用 CHJ_GATEWAY_API_KEY 拉 llm-gateway-proxy.../v1/models → 打印真实模型 id 列表；
2. 依次用 auth_session.json 的 access_token、portal_token 作为 Bearer 探测 portal-k8s-prod.../api/copilot/codex/v1/models → 打印哪一个令牌被接受（HTTP 200 即为通过），并在通过时打印该端点可用的模型 id。

把这两份“模型 id 列表”和“通过的令牌名”回贴给我，我再据此定稿 provider-merge.yml 里的模型清单（不要凭我给的那几个猜测字段，要以网关真实返回为准）。

第 2 步：合并配置到 DSH​

确认 provider-merge.yml 里的模型/令牌符合第 1 步结果后：

# 先看差量预览（不写盘）
D:\bowen\git-project\dsh-ept-integration\apply.ps1

# 确认无误再真正合并（会自动备份 settings.yaml）
D:\bowen\git-project\dsh-ept-integration\apply.ps1 -Apply

第 3 步：写入 ept 令牌（路线 B 用）​

把第 1 步确认可用的令牌写进 DSH 凭据：

D:\bowen\git-project\dsh-ept-integration\refresh-ept-key.ps1   # 交互式从 auth_session 提取并写入 .credentials.yaml

（写入的是 EPT_COPILOT_TOKEN 键；注意 access_token 每天过期，需定期刷新——脚本会提示。）

第 4 步：让 DSH 生效并选模型​

改完 settings.yaml 后重启 dsh web，然后在 Web 的模型选择里切换：

• CHJ LLM Gateway → kivy-deepseek-v4-*（主力）
• EPT Copilot → azure-gpt-5_6-*（新增）

五、注意事项​

• 密钥安全：令牌属于敏感信息，脚本只在内存中使用、不回显；写入 .credentials.yaml 时保持该文件私密。
• 凭据自动刷新：access_token 短有效期（auth_session.json 的 expires_at），企业后台凭据说 refresh_token 可续。用 cron / 开机脚本定期跑 refresh-ept-key.ps1 即可维持。
• 503 抖动：日志曾见 simulated no healthy upstream（deepseek-v4-pro 偶发 503）。属网关上游问题；pi-ai 有重试策略，若频繁可顺手把 CLI 里的重试调高。
• 本沙箱无 VPN 且写盘受限，所以所有实连验证都必须在你的正常终端完成。

Ponytail 是我给 AI 编程工作流写的一套约束：先问这件事是否需要存在，再复用已有代码、标准库和平台能力，最后才增加最小实现。

它约束的不是代码风格​

重点不是“每次都写一行代码”，而是要求 AI 先理解真实调用链，修根因而不是给每个调用方打补丁。懒惰的目标是少维护，不是少思考。

为什么需要显式的跳过项​

很多工程浪费来自“顺手加上”的配置、抽象和扩展点。记录“这次跳过了什么、什么时候才值得加”，能让简化变成有意识的取舍，而不是遗漏。

适合落地到团队吗​

适合把它当 review 清单和 agent 指令，不适合当成拒绝所有复杂设计的教条。安全、数据完整性、可访问性和明确要求，永远优先于少写几行代码。

一个 0 依赖的 DeepSeek Harness 插件， 用来演示 Cordis 插件系统的四个核心机制，并且能在任意目录直接安装。

这个文件夹里的插件就是为 D:\bowen\git-project\dsh-hello-plugin\ 准备的， 不需要放进 DSH 仓库，也不需要联网装依赖。

目录结构与“每步作用在哪”​

dsh-hello-plugin/
├── index.js            # 插件本体（唯一源码，0 依赖）
├── package.json        # 打包安装路线（dsh plugin add）用的 bundle 清单
├── cordis.yml          # 开发期路线：--patch 覆盖层（引用上面的 index.js）
├── cordis.patch.yml    # 打包路线：bundle 在被安装时应用的那一层
└── README.md           # 本文件

index.js 里的插件扮演了这四种角色，各自作用在 DSH 的不同层：

前提​

你的 DSH 是从源码跑起来的（界面上应该是 http://127.0.0.1:3080），且在 D:\bowen\github\deepseek-harness 有可执行的 checkout、pnpm 可用。 （如果不是从源码跑，见「路线 B」。）

路线 A · 开发期安装（最快，推荐）​

这一步不“安装”到任何地方，而是让 DSH 在启动时叠加一层 patch 把插件挂进去。

1. 停掉当前正在跑的 DSH Web（占用 3080 的那个进程）。

2. 在 DSH 源码根目录执行：

   cd D:\bowen\github\deepseek-harness
   pnpm dsh web --patch D:/bowen/git-project/dsh-hello-plugin/cordis.yml
   

3. 打开 http://127.0.0.1:3080。

验证四件事：

• 终端出现 [dsh-hello-plugin] ACTIVE — apply(ctx) 执行 …（插件装上了）。
• 在 UI 开一个新对话 → 终端出现 [dsh-hello-plugin] 生命周期钩子触发 → session/created …（挂上生命周期的证据）。
• 输入：用 greet 工具跟 Ada 打个招呼 → 模型调用 greet，得到 你好, Ada!（工具进流水线的证据）。
• 改一下 cordis.yml 里的 greeting/heartbeatMs 再重启，观察配置生效、旧实例干净卸载。

为什么要用 file:///D:/... 而不是 D:/...？D:\... 会被 Node 当成 URL 的 scheme d: 解析而报错；file:///D:/... 才是合法的模块标识符（见 vendor/loader/src/config/tree.ts 的 import() 解析）。

卸载路线 A：去掉启动命令里的 --patch … 参数即可，或者把 - insert 整段删掉。

路线 B · 打包安装（正式安装进 profile）​

把插件变成一个可通过 dsh plugin 安装的组合包（bundle）。适合分发给别人 / 长期使用。

1. 确认 dsh CLI 可用（源码 checkout 下用 pnpm dsh 代替 dsh）。

2. 在本插件目录安装其 checkout：

   cd D:\bowen\git-project\dsh-hello-plugin
   dsh plugin --profile demo add .
   

   首次使用会初始化名为 demo 的 profile。因为我们声明了 dsh.bundle.patch （见下面），dsh 会把 dsh-hello-plugin 追加进该 profile 的 dsh.profile.bundles。

3. 先只看组合后配置、再启动：

   dsh --profile demo --dump-config     # 会看到 “# == dsh-hello-plugin” 那一层
   dsh --profile demo
   

4. 验证方式同路线 A（打开 Web UI 观察上面四件事）。

这里的 package.json 起了什么作用？

{
  "main": "index.js",                                // 插件入口 = 同一个 0 依赖文件
  "files": ["index.js", "cordis.patch.yml"],         // 发布/打包只带这两个文件
  "dsh": { "bundle": { "patch": "./cordis.patch.yml" } }  // 声明“我是一个组合包，贡献这层 patch”
}

卸载路线 B：

dsh plugin --profile demo remove dsh-hello-plugin   # 同时移除依赖和它贡献的层

从 git / tarball 安装：

dsh plugin --profile demo add ./dsh-hello-plugin-0.1.0.tgz   # 或 github:you/dsh-hello-plugin

（你这份是纯 JS、main 就是构建产物，没有 prepare 构建脚本这道坎，git 安装也安全。）

配置文件一览​

cordis.yml（路线 A 专用）：

- insert:
    - id: dsh-hello-plugin
      name: 'file:///D:/bowen/git-project/dsh-hello-plugin/index.js'
      config:
        greeting: '你好'
        heartbeatMs: 0      # 大于 0 时每秒打印心跳（演示 effect 清理）
        verbose: true

• insert = 往装配树里插入一行；插件加载时 config 会原样传给 apply(ctx, config)。
• 因为没导出 Config schema，这里配置是“透传 + 代码内默认值”的方式。

cordis.patch.yml（路线 B 专用）： 唯一的差别是把 name 换成包名 dsh-hello-plugin， 这样库才在 profile 的 node_modules 里按模块名解析到已安装的代码。

怎么继续扩展​

• 加配置校验 / 默认值：在 index.js 导出 schemastery 的 Config：

  // 需要联网先在本目录 pnpm add @deepseek-ai/schemastery（或复用 DSH 仓库里的）
  import Schema from '@deepseek-ai/schemastery'
  export const Config = Schema.object({
    greeting: Schema.string().default('Hello'),
    heartbeatMs: Schema.number().default(0),
    verbose: Schema.boolean().default(false),
  })
  

  一旦导出了 Config，Cordis 就会用它对 cordis.yml 的 config 做校验并填默认值。

• 对外提供服务：把 apply(ctx) 改成 Service 子类并用 super(ctx, 'hiService') + ctx.provide(...)，别的插件就能 inject: ['hiService'] 拿到它。

• 参考：user/develop/basic、 Cordis primer、 Cordis tutorial。

LICENSE: MIT · 纯演示用途，无外部依赖。

配套总纲：d:\bowen\project\docs\ai-master-learning-plan\AI-Master-12周进阶学习计划.md 开始日期：2026-08-10 原则：深度优先于广度；亲手构建优先于看视频；一个老师学到底 每周投入：10-12 小时（工作日每晚 ~1.5h + 周末半天）

这个仓库是干嘛的​

把 12 周计划落地成一个能直接照着干的工作区：

• 每个阶段一个文件夹，每篇 Wxx.md 就是这一周的「该干什么」清单（学什么 / 交付什么 / 怎么自检）。
• 代码交付物进 04-code/，周记写在每周文档末尾，论文笔记进 06-papers/。
• 完成后勾掉 README 底部的进度表，两周一次回填。

目录结构​

ai-master-12-week/
├── README.md                  ← 你在的地方（入口 + 进度追踪）
├── 01-phase-a-foundation/     # 第 1-4 周 建立直觉
│   ├── phase-a-checkpoint.md  # W4 结束的验收
│   └── W01.md ... W04.md
├── 02-phase-b-build/          # 第 5-8 周 亲手构建
│   ├── phase-b-checkpoint.md  # W8 结束的验收
│   └── W05.md ... W08.md
├── 03-phase-c-prod-papers/    # 第 9-12 周 生产化 + 读论文
│   ├── phase-c-checkpoint.md  # W12 结束的验收
│   └── W09.md ... W12.md
├── 04-code/                   # 全部代码交付物（自己建 git 仓库）
│   └── README.md              # 每个交付物放哪 + GitHub 怎么管
└── 06-papers/                 # 论文笔记
    └── README.md              # 5 篇论文顺序 + 笔记模板

每周循环（规定动作，任何一周都适用）​

1. 学（~5-6h）：看/读本周指定资料，只用一个老师（主线 Karpathy）。
2. 构建（~4-5h）：跑通本周交付物，能给别人演示。
3. 沉淀（~1h）：在对应 Wxx.md 末尾写 150-300 字《本周我搞懂了什么 + 还没懂的》。
4. 存档：每两周回填进度表、更新文档。

三阶段总览​

进度追踪​

• W1 完成
• W2 完成
• W3 完成
• W4 完成 ← Phase A 验收（01-phase-a-foundation/phase-a-checkpoint.md）
• W5 完成
• W6 完成
• W7 完成
• W8 完成 ← Phase B 验收（02-phase-b-build/phase-b-checkpoint.md）
• W9 完成
• W10 完成
• W11 完成
• W12 完成 ← Phase C 验收（03-phase-c-prod-papers/phase-c-checkpoint.md）

常用链接​

• Karpathy YouTube（Intro to LLMs、Zero-to-Hero：micrograd → makemore → nanoGPT）
• 3Blue1Brown 神经网络 + LLM/Attention 系列
• 你司网关文档：d:\bowen\project\docs\LLM\
• 教练：Claude Code 可用来查资料、审你的代码、当你的「同学」

一个痛点开场​

用 AI 干活干多了，我发现最扎心的不是"它写不出来"，而是这三件事：

一是配置天天重来。Claude Code 换了新会话就不认识你；CLAUDE.md、agents、hooks、rules 每个项目都要重新搭一遍，搭完上个项目的经验又带不过来。

二是干完没人把关。让 AI 并行拉起来跑得挺热闹，但「看起来都对」和「真的对」之间差一道独立检核。好几次交付物差点带病出门，就是少了这一道。

三是没有章法。想让 AI 先规划再动手、提交前自查、测试写规范……说一次管一次，换个说法它又忘了。

所以我就在想：能不能把「并行干活、常驻记忆、质量把关、越用越懂我、干活有章法」这几件事，打包成一个开箱即用的东西，不用每次重新解释？

ECC（Everything Claude Code）就是这么长出来的。

一句话说清它是什么​

ECC 是一套「AI 编程工具的配置全家桶」——把 67 个专业子智能体、281 个技能、94 个命令、一套工程规约和安全审计，封装成插件，装进 Claude Code 就能直接用。

它不是针对某个功能的增强，而是把 Claude Code 从"一个能写代码的对话窗口"，升级成一支配置好的 AI 团队。

数据卡片（截至 2026-08，均可复现验证）：

一句话：它解决的不是『AI 写不写得快』，而是『AI 写得稳不稳、有没有人把关、还记不记得你是谁』。

我亲测下来，它到底好在哪​

1. 开箱就是一支「AI 团队」🎯​

不用自己写 planner、code-reviewer、tdd-guide——这些它都配好了：写大功能 /ecc:plan，改完 /ecc:code-review，构建挂了有 build-error-resolver，C++/Go/Rust 各有专属 reviewer。

一句话：67 个 agent，就是一支现成的、各司其职的「虚拟团队」。

2. 281 个技能 = 各技术栈的最佳实践直接抄​

frontend-patterns、backend-patterns、python-patterns、golang-patterns……让 AI 输出的不是"能跑"，而是符合该语言惯用法的代码；tdd-workflow 把"先写测试"变成每次都会执行的流程。

一句话：想少踩坑，就先装一套别人踩完坑沉淀出来的 patterns。

3. 一套规约，让 AI 干活「有章法」​

rules/ 里是必须遵守的硬约束：代码风格、git 规范、80% 覆盖率、提交前安全自查。装完之后，不管开哪个项目，AI 都默认按这套标准干活。

一句话：等于把团队的工程纪律，也"配置化"了。

4. 跨会话记忆 + 持续学习：AI 终于记得我​

hooks 自动在会话开始加载上下文、会话结束存状态；/instinct-status 能看 AI 学到了我哪些习惯，/evolve 把相关习惯聚合成技能。用久了是真的"越用越懂我"。

一句话：新会话里它不再是个陌生人。

5. AgentShield：给 AI 配置上个「安全锁」🤔​

扫描 CLAUDE.md / settings.json / MCP / hooks，查密钥泄露、注入风险、权限过宽。一句话命令就能跑：

npx ecc-agentshield scan

一句话：把 AI 接进生产之前，先让它自己给自己体检一遍。

6. 不止 Claude Code：一套配置，多端通用​

Claude Code / Codex / Cursor / OpenCode / Gemini 都能用——skills 和 rules 的资产可以带走，不被某个工具绑定。

怎么装上就用（完整教程）​

前置条件​

• Claude Code v2.1.0+（ECC 依赖新版插件钩子机制，太老会踩坑）

claude --version

方式一：插件安装（推荐，2 分钟）​

/plugin marketplace add https://github.com/affaan-m/ECC
/plugin install ecc@ecc

⚠️ 早期文档见过 everything-claude-code@everything-claude-code 这种旧标识符，现在统一成 ecc@ecc，以仓库最新 README 为准。

方式二：手动安装（想完全掌握装哪些）​

git clone https://github.com/affaan-m/ECC.git && cd ECC
npm install

# ⚠️ 关键一步：rules 不随插件分发，必须手动复制，否则「规约不生效」
mkdir -p ~/.claude/rules
cp -R rules/common ~/.claude/rules/
cp -R rules/typescript ~/.claude/rules/   # 按技术栈追加 python/golang 等

常用命令速查​

三个容易踩的坑​

1. 别叠加安装：已用 /plugin install 就不要再跑 install.sh --profile full 或 npx ecc-install，会技能重复。
2. MCP 别一下开太多：工具开关太多会挤爆上下文窗口，每个项目实际启用 < 10 个。
3. multi- 命令需额外装运行时*：/multi-plan 这类要 npx ccg-workflow 初始化才可用。

适合谁 / 不适合谁​

🎯 推荐给：

• 重度 Claude Code 用户——少写重复配置、让 AI 干活更规范
• 多语言 / 多项目开发——一套 skills/rules 通用所有技术栈
• 想把"写代码"外包给 AI、但还想保留工程判断力的人——规划 / 评审 / 安全这些"人的活"，它帮你兜底

⚠️ 要谨慎的：

• Claude Code 新手：67 个 agent + 281 个技能信息量巨大，建议先只装 rules + 几个常用 skill
• 不喜欢被规约束缚的人：它会"管教"AI 的行为，自由发挥型会觉得被唠叨
• 只想改一行代码就收工的人：完整规划流程有额外开销

看完立即做（10 分钟落地清单）✅​

1. claude --version 确认 ≥ v2.1.0
2. /plugin marketplace add https://github.com/affaan-m/ECC + /plugin install ecc@ecc
3. 手动补 rules（git clone + cp rules/common、rules/typescript 到 ~/.claude/rules/）
4. npx ecc-agentshield scan 给现有配置体检一遍
5. 随手试一下 /ecc:plan "给当前项目加个用户认证"

🚀 装上之后你会发现：AI 干活的方式，从"你要什么我给什么"，变成了"我按工程标准帮你把关、把成果交给你验收"。

参考资料：

• GitHub 仓库：affaan-m/ECC ｜ 官网：ecc.tools
• 作者 @affaanmustafa 的官方精简指南 / 长文指南 / 安全指南
• 许可：MIT，可直接用、可改造，记得给个 star

本文为个人亲测分享，所有数字均可到仓库 README 复现验证。

提报人：张博文