Soulize/hard-flash

hard-flash
hard-flash

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

这个 preset 适合优先追求正确性而非速度、完整能力而非玩具式演示、真实路径验证而非仅仅看起来可行的代码的用户。

本包有意保持精简：preset composition 负责声明可用的 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 运行使用了相同的 preset 形态，并表现出几乎相同的语言指纹，但报告分数分别为 85.7 和 42.9。

同一讨论还记录了提示词注入可以改变 we、let me、I 等表达方式，但并不能可靠地改变生成软件的质量。

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

Issue #2 记录了一个相关的兼容性问题：对于非官方 DeepSeek API，dsh 可能会保留现有的 system prompt，并追加 You are a helpful assistant.，而不是删除或替换原始 prompt。
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。

来自 dsh-router-standard 0.2.0 的参考中国象棋结果
图 1——代表性基线结果及玩家 vs AI 交互路径。

额外的参考中国象棋结果
图 1a——同一对比组中的另一张基线截图。

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

最终界面包含更丰富的棋盘呈现、着法历史、状态控件，以及更偏向验证的工作流程。

hard-flash 中国象棋结果
图 2——显示棋盘状态和着法历史的 hard-flash 代表性结果。

额外的 hard-flash 中国象棋结果
图 2a——同一对比组中的另一张 hard-flash 截图。

报告的短语计数如下；它们是本次对比中的诊断信号，而非软件质量评分。

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

关键设计结论并不是某一种短语模式本质上更好，而是提示词应迫使工程证据比对话风格更重要。

因此，hard-flash 强调检查、规划、基于真实接口实现、设置检查点、编译或测试、走通真实用户路径，并在每次修复后重新测试。

源链接

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

hard-flash 改变了什么

路由器注入一条稳定的工程提示词，而不是依赖一系列脆弱、后期且针对具体会话的提示词变更。
注入一段稳定的工程提示词，不依赖脆弱的、晚到的、按会话变化的提示词动态修改。

The prompt first reconstructs the current context, then requires deep planning, concrete decomposition, exact interface inspection, incremental checkpoints, and real user-facing verification.
这段提示词要求模型先重建当前上下文，再进行深度规划、具体拆解、精确接口检查、增量 checkpoint 和真实用户路径验证。

Broad build requests are expanded into a concrete implementation specification instead of being silently reduced to a toy example, a mockup, or a disconnected proof of concept.
宽泛的 build 需求会被展开为具体实现规格，而不是被悄悄缩水成 toy example、表面 mockup 或脱离系统的 proof of concept。

The model is told to implement against the actual codebase and actual installed interfaces, not against memory, guesses, or invented APIs.
模型被要求基于真实代码库和真实安装版本的接口实现，而不是依靠记忆、猜测或虚构 API。

Every completed file or TODO step is treated as a checkpoint where the surrounding architecture, symbols, signatures, state, call path, and integration assumptions are reviewed again.
每完成一个文件或 TODO 步骤都要进行 checkpoint，重新检查周边架构、符号、签名、状态、调用路径和集成假设。

Verification is a loop: test, debug, fix, and retest until the intended user-facing path works correctly.
验证是一个闭环：测试、调试、修复、重新测试，直到预期的真实用户路径正确工作。

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，直到正确。
Three first-turn modes
三种首轮模式

The router initializes different first-turn tools for normal, plan, and goal work, then promotes the session to the full available catalog after a durable tool call.
路由器会为 normal、plan 和 goal 工作分别初始化不同的首轮工具，并在出现持久化 tool call 后把会话提升到完整可用工具目录。

normal
normal（普通执行）

Normal is the default when plan mode is not active and the request does not contain a long-running goal signal.
当 plan mode 没有激活且请求没有长任务目标信号时，路由器使用 normal 模式。

The first-turn core is read, write, edit, plus the platform shell (pwsh on Windows or bash on Unix-like systems).
normal 首轮核心工具是 read、write、edit，再加上平台 shell（Windows 使用 pwsh，类 Unix 系统使用 bash）。

This mode is optimized for directly implementing a bounded change while still requiring inspection and verification through the shared prompt.
这个模式适合直接实现边界清晰的变更，同时仍然受统一提示词约束，必须进行检查和验证。

plan
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 的选择。

如果确认安装目录中没有用户添加的文件，可以只删除 .agent-presets 下的 hard-flash 目录来移除 preset。

不要为了卸载这个 preset 而删除整个 .dsh 目录，因为那可能同时删除无关的 dsh 设置、凭据、缓存或其他 preset。
设计说明

路由器在所有模式中保持共享 Base 提示词稳定，并保留 dsh 提供的 plan policy 部分。

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

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

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

组合保留了原始 preset 中记录的 host-plane 行为，包括 shell 环境、注册表、持久化和模型路由边界。

不要随意将 host-plane 服务移入 entry-local realm，因为注册表生命周期和跨会话可见性是 dsh 集成契约的一部分。

仓库状态

该仓库包含可部署的 preset 文件，不需要构建步骤或生成产物。

assets/ 下的四个 PNG 文件仅作为文档证据；安装程序不会将它们复制到 dsh preset 目录中。

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

发布到 GitHub 时，请提交所有七个根文件以及 assets/ 下的全部四个 PNG 文件，以确保相对路径 ./router-bootstrap.mjs 导入和截图链接保持有效。

由于提供的 hard-flash 包未包含许可证声明，因此未自动添加许可证；在发布前，请添加与您预期分发方式相匹配的许可证。

致谢

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