懒人工作流 elvinzhao10/LazyDeepSeek

LazyDeepSeek

LazyDeepSeek

描述工作。保留计划。证明结果。

LazyDeepSeek 帮你在 DeepSeek Harness 里使用结构化、有证据支撑的工作流。它准备本地包资源和指引；只有在全新会话中观察到主机加载成功，才算主机就绪。

平台状态 · 快速上手 · 主机路线 · 1.3.5 说明 · 家族 · 文档

当前包版本：v1.3.5。主机就绪状态：待定。 本地检查和发布归档只能证明包本身的行为；加载、命令/技能执行和 MCP 连接必须由全新主机会话来证明。

1.3.5 有什么

- 运行时检查会走真实的包路径和生命周期路径；未知的演练和失败的检查无法报告成功。
- 核心和可选的 TypeScript LSP 依赖分开检查，包括不受支持的运行时。
- 钩子输入在解析前先做边界限制，并且不进入进程参数。
- 平台指南区分当前原生能力、旧路线和等待实机验收的集成。

这是一个维护版本。它包含家族自 v1.3.0 起引入的工作流基础，以及后续的可靠性工作。对 Kimi 和 DeepSeek 来说，这描述的是继承来的家族行为，不是这两个移植版此前的公开发布。下面的细节描述 v1.3.5 累积起来的体验；发布说明区分了本次补丁的修复和继承来的功能。没有提出任何新的速度、省 token 或成本方面的说法。

| 家族里程碑 | 当前包给你什么 |
| v1.3.0 基础 | 自然语言入口、可编辑计划、持久决策和验证层级。 |
| v1.3.1 可靠性 | 更清晰的执行意图、更安全的隔离和证据对比。 |
| v1.3.2 交接 | 绑定修订版本的验证报告契约；通用完成 API 有单独的限额。 |
| v1.3.3 加固 | 针对具体主机的钩子、MCP 和发布修复。 |
| v1.3.4 维护 | 事务化的运行完整性、更安全的生命周期和原生适配器修复。 |
| v1.3.5 修复 | 真实运行时演练、有边界的钩子、依赖更新和当前平台指南。 |

直接说，或者用命令——都行

两种入口路线最终汇到同一个执行权限和同一套关卡：

- 自然语言：平实地描述工作——「修复欢迎标签里的错别字」——系统会选出最小够用的工作流并运行。
- 显式命令：/lazy-ulw-plan <idea> 构建新计划，并且 /lazy-start-work <plan> 执行已知计划。权限相同，关卡相同。

清晰的实现请求不需要命令。反过来，要求解释、引用命令，或说「只做计划」，永远不会碰你的文件：持久化的 execution_intent 保持 plan_only，直到你真正要求执行；含糊的「ok」加上几个悬而未决的问题，本身永远不会授予执行权限。

工作运行时可以编辑的计划

计划是你拥有的 Markdown。运行中途编辑它们；harness 会在执行边界处协调你的改动，而不是覆盖它们：

- 表面措辞和顺序调整会保留已有证据。
- 语义改动（验收、依赖、验证命令）只会让受影响的任务及其依赖项失效——无关工作不受影响。
- 你的复选框是断言，不是裁决：仅勾选复选框永远不算验证完成，取消勾选会重新打开任务。

harness 记住的决策

跨计划决策存放在持久账本（.lazydeepseek/decisions/ledger.jsonl）中。当计划二遇到计划一已经回答过的问题——且有证据——它会回忆该决策，而不是重新问你。矛盾会以取代的形式呈现，缺陷会变成有范围的修正，只阻塞受影响的工作，记忆中的任何内容都不能覆盖你当前的指令。

验证规模与改动匹配

工作流要求验证规模与改动匹配：文档检查（V0）、聚焦检查（V1）、集成场景（V2），或全面的安全/发布关卡（V3，通常在 CI 中）。有效证据在其输入匹配时可以复用；受影响、缺失或过期的检查必须重跑。原生执行仍需在所选宿主中获得验收。

里程碑、决策关卡，以及完整的状态/版本语义，与 LazyBuddy、LazyTrae 和 LazyQoder 逐字节共享（见 plugins/lazydeepseek/contracts/lazyseries-shared-semantics.v1.json）。DeepSeek Harness 的路由边界不变：包选择永远不能证明宿主激活。

推荐：借助 AI 安装

在项目中打开 AI 编码助手，粘贴以下内容：

帮我从 https://github.com/elvinzhao10/LazyDeepSeek 为这个项目安装 LazyDeepSeek。阅读仓库的 AGENTS.md 和安装指南。先验证根包清单并运行安全的包检查。指导我完成针对该 GitHub 仓库、固定到某个 commit sha 的 dsh git-spec 安装，然后在新会话中验证已安装的插件。安装或启用插件前先问我。

助手可以运行本地检查并指导宿主步骤。安装或启用插件会授予其代码执行信任，所以在审查源码后，在 DeepSeek Harness 中批准这些操作。

手动设置

直接配置档设置

1. 确认固定的宿主：dsh --version 报告确切的 0.2.0-rc.2。
2. 批准后，运行 git-spec 安装，仓库 URL 固定到完整提交 SHA（或 GitHub release tarball，或本地开发检出用 ./lazydeepseek）。这个包不走 npm registry。
安装后的插件默认启用；不会运行构建脚本，因为预构建的 lib/ 已提交。
升级现有安装时，把新的已验证 release SHA 装进同一个配置档，然后重启会话，让生成的钩子配置重新解析。
3. 你需要 Node.js LTS 24（推荐）或 22（支持的备选） —— 生命周期也接受 Node.js LTS 20 以兼容 —— 以及 Git 在 PATH 上，供本地启动器使用。在新任务里试试：模型调用已加载的技能时，技能会通过 Skill 工具出现；注册的命令在支持的地方可能以交互条目出现，比如 /lazy-ulw-plan；去观察它们，不要从注册情况推断可见性。

原生引导

bash scripts/install.sh 会验证 Node.js LTS 20+ 和 Git，校验根 dsh bundle manifest 与 route contract，运行包加载检查和插件 doctor，并打印带 GitHub URL 的配置档级 dsh plugin 安装步骤（macOS 上会复制到剪贴板）。加上 --project <absolute-project-root> 还会运行持久生命周期引导。在 DeepSeek Harness 里，/lazy-onboard、/lazy-update、/lazy-offboard 命令会一步步引导你完成引导、更新和安全移除。上面的 git-spec 配置档步骤仍是标准做法，包检查永远不能证明宿主就绪 —— 脚本最后会打印 HOST READINESS: PENDING，直到新会话显示一个真实技能/命令和全部六个 MCP 连接。

持久生命周期

想完全掌控时，可以手动设置。你需要 Node.js LTS 24（推荐）或 22（支持的备选） —— 生命周期也接受 Node.js LTS 20 以兼容 —— 以及 Git，还有以 python3 提供的 Python 3.10+。从已验证的 origin https://github.com/elvinzhao10/LazyDeepSeek 开始，按安装指南操作。

上面的 git-spec 安装是主要路线。想要能扛住源码检出的持久安装，先运行一次 onboard 创建持久安装；之后用稳定启动器执行 update、status 和安全 offboard：

node "<install-root>/LazyDeepSeek/launcher.js" status --project "<absolute-project-root>"

「就绪」是什么意思

- 包就绪指复制后的包和本地检查都有效。
- 宿主就绪需要新宿主会话、一个真实 Skill 或命令，以及每个预期的 MCP 连接。

在观察到这些之前，诚实的结果是 HOST READINESS: PENDING。
本地文件和加载检查永远不能证明宿主加载了插件。

默认的包 doctor 不会从 PATH 发现或执行 dsh。可选的宿主 manifest 校验是显式操作，使用 bash scripts/lazydeepseek-plugin-doctor.sh --host-validator /absolute/path 在 plugins/lazydeepseek/ 下运行。
发布校验器会串行跑分类 shell 回归，用保守的 Node 并发跑所有包内 tests/*.test.js，再跑 tests/ 和 tooling/ 下的 Python 测试；它的 JSON 会分别列出这些结果。

选一条路线

每个项目只选一条路线：

- DeepSeek Harness git-spec 安装（dsh-plugin-git-sha）是默认的完整插件路线：技能、命令、原生角色工具、七个桥接钩子事件、六行 MCP 都从同一个 bundle 组合而成；新会话加载单独观测。

技能加手动 MCP 连接器只是恢复用的（manual-skills-mcp-fallback）选项。同一个项目不要在全插件路线旁边再跑这个回退方案。停掉会话，只通过宿主 UI 删掉 LazyDeepSeek 之前的条目，选一条路线，再开新会话验证。

设计思路

先想清楚你要的结果，以及你怎么知道它成了。然后用刚好够用的结构去匹配任务。你完全可以用大白话描述要做的事；这些模式是参考，不是必须背下来的命令。v1.3.0 引入的双入口路由会替你选一个。

| 模式 | 什么时候用 | 示例请求 |
| Direct | 改动小且明确。 | “修掉这个错误，跑相关测试。” |
| Assisted | 你需要有人帮你理解陌生的区域或失败。 | “帮我找出这条命令为什么失败，然后验证修复。” |
| Planned | 工作分好几块，或者有重要取舍。 | “先给这个功能做个计划，再动文件。” |
| Orchestrated | 工作涉及发布、安全，或者有风险的改动。 | “审查这次发布，准备好发布材料。” |
| Long-horizon | 目标要跨会话持续推进。 | “带着检查点继续做这个迁移。” |

宿主改动要慎重

LazyDeepSeek 不自动化凭据、OAuth 值、私有 registry 或信任设置。任何由宿主管理的操作，它都会先请求批准，并把安全的包检查与原生插件安装、连接器改动分开。

包内清单

| 层面 | 数量 | 作用 |
| 技能 | 19 | 面向宿主的流程策略，覆盖规划、执行、审查、验证。 |
| 命令 | 20 | 这些流程策略的具名宿主入口（斜杠菜单条目）。 |
| 智能体 | 13 | 规划、实现、QA、安全、上下文方面的专家角色定义。 |
| 钩子事件 | 声明 9 / 桥接 7 | SessionStart、UserPromptSubmit、PreToolUse、PostToolUse、Stop、SubagentStart、SubagentStop 原生桥接。PermissionRequest 和 PostToolUseFailure 是降级合成；子事件仅供参考。 |
| MCP 声明 | 6 | 本地服务，用于 ledger、验证、状态、上下文、代码智能和文档。 |

LazySeries 家族

一套工作流理念，六种宿主集成。 按你用的宿主挑对应分支；每个分支保留自己的原生适配器、安装路径和验收证据。这些包各自独立运行。

| 分支 | 目标宿主 |
| LazyBuddy | CodeBuddy CLI / IDE · WorkBuddy |
| LazyTrae | TraeCode / TraeWork / TraeCode CLI |
| LazyQoder | Qoder CLI / IDE / app |
| LazyZCode | ZCode |
| LazyKimi | Kimi Code CLI · Kimi Work（实验性） |
| LazyDeepSeek ← 你在这里 | DeepSeek Harness 0.2.0-rc.2 |

这一系列共用同一套规划、证据、决策记忆和完成契约。首个共享验证核心已内置到每个包；产品适配器把宿主设置和权限保持显式。契约一致，不代表宿主能力可以互换。尤其是 LazyKimi 的 Kimi Work 仍属实验性，DeepSeek 的合成事件也不是原生钩子。安装前请先读对应分支的宿主指南。

技术参考与评估

源码层面的说明在 docs/README.md。它用与实现对应的图示，梳理包结构、请求流程、状态模型、安全边界、MCP 生命周期和发布检查。

想逐项对比原始 LazyCodex 设计，看 LazyDeepSeek 实现了什么、又在哪些地方有意不同，请读 lazydeepseek-evaluation.md。

LazyDeepSeek 主要受 LazyCodex 启发。署名信息及其与 OmO 的关系记录在 NOTICE。它是独立实现，运行时不需要 LazyCodex 或 OmO。

了解更多

- 安装并验证宿主
- 工作流手册 —— 各模式如何挑活
- 证据与完成 —— 「做完」能证明什么
- 宿主路由与恢复
- 发布说明
- 文档索引

许可证

MIT。署名与来源见 NOTICE。

参与贡献

欢迎提 issue 和 pull request。开发检查、发布预期，以及如何上报脱敏后的复现细节，请读 CONTRIBUTING.md。安全漏洞请按 SECURITY.md 私下上报。