硬核闪击 Soulize/hard-flash

hard-flash

hard-flash

hard-flash 是 DeepSeek Harness（dsh）的智能体预设，目标是在第一轮就让大型工程任务进入深思熟虑、强集成、可验证的工作状态。

这个预设适合这样的用户：优先追求正确率而不是速度，优先追求完整能力而不是玩具演示，优先追求真实路径验证而不是仅仅看起来可行的代码。

本包有意保持精简：预设组合负责声明可用的 dsh 工具，router-bootstrap.mjs 负责首轮路由和统一的工程执行纪律。

背景与动机

hard-flash 源于一个工程观察：对于 DeepSeek V4 Flash，可见的思维链风格并不能可靠反映最终工程交付的质量。

推动这个方向的两个原始 GitHub 讨论是 dsh-router-standard issue #18 和 v4-flash-godmode-opencode-go issue #2。

Issue #18 记录了一项描述性研究：同一宽泛任务上的十二个会话，其中一个配置以 UP2 形式重复运行；它明确提醒样本很小，不能被解读为因果证明。

其中最有工程意义的信号是：思维链不等于质量。UP 和 UP2 使用相同的预设形态，表现出几乎相同的语言指纹，但报告分数分别为 85.7 和 42.9。

同一讨论还记录：提示词注入可以改变 we、let me、I 这类表达，却无法可靠改变生成软件的质量。

在这些证据中，提示词更像是行为开关，而不是质量开关；实现细节、验证深度和偶发失败仍然是决定性因素。

Issue #2 记录了一个相关的兼容性问题：对于非官方 DeepSeek API，dsh 可能会保留原有系统提示词，并追加 You are a helpful assistant.，而不是删除或替换原提示词。
Issue #2 记录了相关的兼容性问题：对于非官方 DeepSeek API，dsh 可能保留原有系统提示词，并在后面追加 You are a helpful assistant.，而不是删除或覆盖原提示词。

这个 issue 不是严格的质量基准实验，但它与一个实践观察相符：即使不清除原系统提示词，只在后面追加一句很短的提示，也可能改变模型行为。

因此，我们的工作假设不是「让思维链看起来更深」：Flash 的质量往往更受幻觉率、遗漏的集成假设以及验证是否能在交付前捕获错误的影响。

当相似的可见思维链模式下，同类任务有时成功、有时失败时，体验就像从高方差分布中抽取结果；我们用「抽卡」简称这种运行间不确定性。

这是一个工程假设和设计依据，并不是关于所有 Flash 模型、任务或 provider 配置的普遍定理。

有意进行的资源交换

hard-flash 的应对方式是用更多时间和 token 预算，换取更低的幻觉交付和未经验证交付概率。

在这次对比记录中，同一段 hard-flash 提示词相较于 dsh-router-standard 0.2.0 提示词配置大约使用了 1.5 倍工作时间、5 倍输入 token 和 3 倍输出 token。

这些比例是本次对比中的观察值，不是适用于所有 provider 和任务的通用基准，也不是固定承诺。

设计目标很直接：当正确率比延迟更重要时，把更多预算投入到检查、架构、集成、checkpoint 和真实路径验证上。

受控对比：中国象棋网页任务

这次对比没有引入视觉模型；有意控制的变量是系统提示词，而不是更换模型。

提示词：制作一个网页版中国象棋游戏，有AI vs AI 以及玩家 vs AI，需要资料 素材 纹理等可以联网查找

基线使用 dsh-router-standard 0.2.0 的提示词运行一轮，并且没有使用运行时注入。
基线结果在视觉上可用，但玩家 vs AI 流程存在一个已报告的 bug：切换难度后页面可能会变回 AI vs AI。

Reference Chinese-chess result from dsh-router-standard 0.2.0
图 1——基线结果及玩家 vs AI 交互路径的代表性截图。

Additional reference Chinese-chess result
图 1a——同一对比组中的另一张基线截图。

hard-flash 运行同一个任务，使用本仓库描述的强工程约束型系统提示词。

最终界面包含更丰富的棋盘表现、着法记录、状态控制和更偏向验证的工作流程。

Hard-flash Chinese-chess result
图 2——显示棋盘状态和着法记录的 hard-flash 代表性结果。

Additional hard-flash Chinese-chess result
图 2a——同一对比组中的另一张 hard-flash 截图。

这次对比中记录的短语计数如下；它们是诊断信号，不是软件质量分数。

| System prompt / 系统提示词 | Let me | I'll | We | need | Let's |
| hard-flash | 356 | 99 | 198 | 66 | 1 |
| minimal | 0 | 4 | 218 | 98 | 87 |

关键设计结论不是某一种短语模式天然更好，而是系统提示词应该让工程证据比对话风格更重要。

因此，hard-flash 强调 inspect、plan、基于真实接口实现、checkpoint、编译或测试、运行真实用户路径，并在每次修复后重新测试。

原始链接

- 主要实验讨论是 dsh-router-standard issue #18。
- 相关的系统提示词兼容性讨论是 v4-flash-godmode-opencode-go issue #2。

hard-flash 改变了什么

路由器注入一段稳定的工程提示词，不再依赖一串脆弱的、在会话后期才注入的提示词变更。
注入一段稳定的工程提示词，不依赖脆弱的、晚到的、按会话变化的提示词动态修改。

这段提示词要求模型先重建当前上下文，再进行深度规划、具体拆解、精确接口检查、增量 checkpoint 和真实用户路径验证。

宽泛的 build 需求会被展开为具体实现规格，而不是被悄悄缩水成 toy example、表面 mockup 或脱离系统的 proof of concept。

模型被要求基于真实代码库和真实安装版本的接口实现，而不是依靠记忆、猜测或虚构 API。

每完成一个文件或 TODO 步骤都要进行 checkpoint，重新检查周边架构、符号、签名、状态、调用路径和集成假设。

验证是一个闭环：测试、调试、修复、重新测试，直到预期的真实用户路径正确工作。

deep inspect
↓
deep planning
↓
todo decomposition
↓
inspect exact interfaces
↓
write file A
↓
FULL FILE REVIEW + automated validation
↓
write file B
↓
FULL FILE REVIEW + automated validation
↓
complete TODO 1
↓
CROSS-FILE INTEGRATION REVIEW
↓
revise plan if needed
↓
TODO 2
↓
...
↓
complete implementation
↓
REAL USER-FACING TEST
↓
debug
↓
fix
↓
retest
↓
final
1. CONTEXT
先理解已有工作，不重复。

2. DEEP PLAN
实现前充分 inspect，把需求、架构、依赖、接口、 integration、edge cases、failure modes、verification 想清楚。

3. EXPAND BUILDS
宽泛 build 自动展开完整需求和子系统，不缩水成 demo。

4. IMPLEMENT AGAINST REALITY
基于真实代码和真实接口实现。
不确定 symbol/API 就查定义，禁止凭记忆编造。

5. CHECKPOINT
每完成一个文件/TODO，重新读取和复核，检查 symbol、signature、state、call path、integration，并执行适用的 compile/typecheck/test。

6. REAL-PATH VERIFICATION
最后跑真实用户路径。
失败就 debug → fix → retest，直到正确。

三种首轮模式

路由器会为 normal、plan 和 goal 工作分别初始化不同的首轮工具，并在出现持久化 tool call 后把会话提升到完整可用工具目录。

normal

当 plan mode 没有激活且请求没有长任务目标信号时，路由器使用 normal 模式。

normal 首轮核心工具是 read、write、edit，再加上平台 shell（Windows 使用 pwsh，类 Unix 系统使用 bash）。

这个模式适合直接实现边界清晰的变更，同时仍然受统一提示词约束，必须进行检查和验证。

plan

当 dsh plan mode 组装出的提示词中存在有效的 plan:policy section 时，路由器选择 plan 模式。

plan 首轮核心工具是 read、glob、grep 和 exit_plan_mode，再加上平台 shell。

规划首轮有意不暴露 write 和 edit，让模型先检查仓库并提交一个决策完整的计划，再进入实现阶段。

agent.cordis.yml 内的 plan policy 会让 plan mode 持续到 exit_plan_mode 成功，或用户主动切换会话模式为止。

goal（持续目标模式）

当会话已有未完成且未阻塞的 active goal，或当前请求包含长期运行、自主执行等信号时，路由器选择 goal 模式。

goal 首轮核心工具是 read、write、edit、可用的目标工具（get_goal、create_goal、update_goal），再加上平台 shell。

只有当 dsh 工具目录中确实存在 goal 工具时，路由器才会加入这些工具，因此不会虚构不可用的工具。

目标分类器同时识别中英文长期任务信号，包括持续工作、多轮迭代、自主执行以及“直到完成”等表达。

首次持久化工具调用后的提升

在首次持久化 tool/call 事件之前，路由器只暴露上面定义的模式专属核心工具面。

一旦会话历史中出现持久化 tool call，路由器就会移除首轮工具过滤，返回完整组装工具，同时保留 hard-flash persona 和 plan policy。

这样可以得到一个聚焦任务的窄入口，同时不会永久剥夺 agent 的完整能力。

已经包含持久化 tool call 的恢复会话会立即进入提升状态，不会被当成全新的空会话。

工程执行路径

推荐的执行顺序是深度 inspect、深度 planning、TODO decomposition、精确接口检查、逐文件实现和验证。

每处理完一个文件，agent 都会先做一次完整的文件审查和自动化验证，再继续下一个文件。
每完成一个文件，agent 都要进行完整文件复核和自动化验证，然后再继续下一个文件。

每完成一个 TODO，agent 都要进行跨文件集成复核；如果新证据改变了架构，就要修订计划。

最后阶段会运行真实用户路径；如果发现任何问题，就进入测试、调试、修复、重新测试的闭环。

优先级排序是正确率 ＞ 能力发挥 ＞ 时间和 ＞ token 效率。

仓库文件

agent.cordis.yml 声明 dsh composition，包括平台 shell、文件系统工具、目标工具、plan mode、压缩、委派、workflow、web 和任务工具。

router-bootstrap.mjs 注入统一提示词、分类请求、选择首轮工具集，并在持久化 tool call 后提升会话能力。

preset.yml 为 preset 提供 dsh preset 系统中的显示名称、描述和加载顺序。

install.sh 在 Linux 和其他类 Unix 系统上安装 preset，不需要额外依赖包。

install.ps1 在 Windows PowerShell 上安装同一组文件，并使用 SHA-256 校验复制后的内容。

.gitattributes 固定 shell 和源码文件使用 LF 格式，避免跨平台 Git checkout 后 Linux 安装脚本因换行符变化而无法执行。

assets/ 保存本 README 引用的四张对比截图，并使用可在 GitHub 正常渲染的仓库相对路径。

运行要求

你需要安装支持 agent preset、Cordis composition 文件、system-prompt/assemble hook 以及 agent.cordis.yml 中工具名称的 dsh 版本。

hard-flash 不会代替你安装 dsh、模型 provider、凭据或外部插件。

路由器是由 dsh 加载的 JavaScript；部署脚本只使用 shell 或 PowerShell 内置能力以及标准文件复制命令。

这个 preset 至少要求 dsh 工具目录提供一个平台 shell，否则路由器会报告 router-bootstrap: no platform shell in catalog。

Linux 安装

克隆或下载本仓库，进入仓库根目录，然后运行安装脚本。

chmod +x install.sh
./install.sh

如果下载方式没有保留可执行权限，也可以通过 Bash 直接调用。

bash install.sh

默认目标目录是 ~/.dsh/.agent-presets/hard-flash。

安装脚本只更新 agent.cordis.yml、preset.yml 和 router-bootstrap.mjs，不会删除 preset 目录，也不会改写无关文件。

如果 dsh 使用非标准配置目录，可以使用 --dsh-root。

bash install.sh --dsh-root /path/to/.dsh

如果你确实要使用另一个 preset 名称安装副本，可以使用 --preset-name。

bash install.sh --preset-name hard-flash-dev

使用 --dry-run 可以只查看目标路径，不创建或复制文件。

bash install.sh --dry-run

Windows 安装

在仓库根目录打开 PowerShell，然后运行安装脚本。

.\install.ps1

如果当前进程策略阻止本地脚本，可以只为当前 PowerShell 进程临时放行，然后重新运行安装脚本。

Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass
.\install.ps1

Windows 默认目标目录是 C:\Users\<你的用户名>\.dsh\.agent-presets\hard-flash。

对于你提供的机器，预期目标目录就是 C:\Users\wang\.dsh\.agent-presets\hard-flash。

Windows 安装脚本不依赖当前工作目录，因为它会相对于 install.ps1 定位源文件。

非默认部署可以使用 -DshRoot、-PresetName 或 -DryRun。

.\install.ps1 -DshRoot 'D:\dsh' -PresetName 'hard-flash-dev'
.\install.ps1 -DryRun

Windows 脚本会逐个比较源文件和目标文件，如果任何哈希不一致就会失败。

将 hard-flash 设为默认 preset

安装脚本有意不自动改写 settings.yaml，因为不同 dsh 版本和用户配置布局可能不同，自动重写 YAML 可能破坏无关配置。

安装完成后，如果你的 dsh 版本使用标准 preset 配置格式，请在配置中添加或合并下面的内容。

agent-presets:
default: hard-flash

如果配置中已经存在 agent-presets 映射，请保留其他键，只修改 default 值。

如果你的 dsh 版本通过其他命令或界面选择 preset，请在那里选择 hard-flash，不要机械照抄这段配置。

修改 active preset 后请重启 dsh，让新 composition 在新会话中挂载。

使用方式

安装后启动新的 dsh 会话，像平常一样提交任务；路由器会读取会话状态并选择首轮模式。

普通边界清晰的工作可以直接使用 normal 请求，例如“增加一个校验命令并测试它”。

如果你希望先检查仓库并得到决策完整的实现计划，再开始修改，请显式进入 plan mode。

如果任务需要跨多轮持续推进，可以使用 goal 语义，例如“持续迭代，直到功能完成并验证通过”。

分类器使用持久化 inbox splice 历史，而不是依赖瞬时局部变量，这也让恢复会话更可靠。

验证清单

确认三个 preset 文件已经出现在预期的 .agent-presets/hard-flash 目录中。

确认 preset 元数据仍然使用 hard-flash 名称，并且没有冲突的加载顺序。

启动新会话，确认 normal 首轮暴露 read、write、edit 和平台 shell。

进入 plan mode，确认规划首轮暴露 read、glob、grep、exit_plan_mode 和平台 shell，但不暴露 write 或 edit。

创建或恢复一个 goal，确认 goal 首轮包含可用的目标生命周期工具。
首次持久化 tool call 之后，确认完整 dsh 目录可用，并且路由器 persona 仍然存在。

真实 build 时，检查生成或改动过的文件，运行相关 type checker、compiler、linter 或 targeted tests，然后走一遍真实用户路径。

任何检查失败，都要排查原因、修复实现，再重复验证闭环，不要在第一个看似可行的结果处停下。

故障模式与恢复

如果路由器报告没有平台 shell，检查 agent.cordis.yml，确认 dsh host composition 在类 Unix 系统暴露 bash、在 Windows 暴露 pwsh。

如果缺少 goal 工具，路由器会把它过滤掉，而不是凭空造一个；需要目标生命周期操作时，安装或启用 dsh goal 工具。

如果缺少 plan 工具，确认 dsh plan mode 按本 preset 使用的名称注册了 plan:policy 和 exit_plan_mode。

如果 preset 能加载，但模型没按预期行为走，先检查组装后的 system prompt 和持久化会话事件，再改路由器。

如果新版 dsh 改了事件名、工具名或 assembly contract，按实际安装的定义更新路由器，不要猜兼容性。

更新与卸载

更新已有安装时，把仓库文件替换成新版本，再跑一遍同一个安装脚本。

安装脚本只覆盖本仓库管理的三个文件，目标 preset 目录里的无关文件保持原样。

停用 preset 时，选择其他 dsh preset，或从配置里移除 agent-presets.default 的选择。

确认安装目录里没有用户添加的文件后，想删掉已安装的 preset 目录，只删 .agent-presets 下的 hard-flash 目录即可。

不要为了卸载这个 preset 就删掉整个 .dsh 目录，那样可能一并删掉无关的 dsh 设置、凭据、缓存或其他 preset。

设计说明

路由器在所有模式中保持统一 Base 提示词稳定，并保留 dsh 提供的 plan policy section。

请求分类器先检查 plan mode，再检查 active goal 状态，然后检查长期任务信号，最后回退到 normal。

active goal 折叠逻辑理解 goal change 事件，包括清除目标以及 complete 或 blocked 终态。

shell 会从组装后的工具目录中选择，优先使用可用的 pwsh，否则使用 bash。

composition 保留原始 preset 中记录的 host-plane 行为，包括 shell environment、registry、持久化和模型路由边界。

不要随意把 host-plane service 移进 entry-local realm，因为 registry 生命周期和跨会话可见性属于 dsh 集成契约的一部分。

仓库状态

本仓库包含可直接部署的 preset 文件，不需要构建步骤或生成制品。

assets/ 下的四张 PNG 图片只用于文档证据；安装脚本不会把它们复制到 dsh preset 目录。

部署脚本会执行本地文件校验，但运行时兼容性仍取决于已安装的 dsh 版本和启用的插件目录。

发布到 GitHub 时，请同时提交根目录七个文件和 assets/ 下的四张 PNG 图片，以保证相对路径 ./router-bootstrap.mjs import 和截图链接都有效。

由于你提供的 hard-flash 包没有包含许可证声明，本仓库没有自动添加 license；正式发布前请补充符合你分发意图的许可证。

致谢

https://github.com/xiaobright/dsh-anchored-standard
https://github.com/yjh051108/dsh-router-standard