laily
146182c1b9
把一次会话复盘中确认的浪费动作固化为硬规则，面向 DeepSeek Flash / DeepSeek V4.1 Flash：先验证再实现、搜索必须有边界、只在被要求的范围内动作 （改项目外目录先问）、命令一次写对、测试按影响面、要求与实测冲突时报告并 等待确认而不擅自改需求。 不设运行时模型判定，只在 description 与正文标记适用范围，避免留出「模型标识 不匹配就不遵循」的逃生口。真实案例与代价放在 references/anti-patterns.md。
88 lines
4.0 KiB
Markdown
88 lines
4.0 KiB
Markdown
---
|
||
name: fixds
|
||
description: >-
|
||
DeepSeek Flash 系模型的行为约束：先验证再实现、搜索必须有边界、不越权改需求
|
||
或项目外目录、命令一次写对、测试按影响面。用于 DeepSeek Flash / DeepSeek
|
||
V4.1 Flash（模型标识含 deepseek 与 flash）；用户说 fixds 时同样生效。
|
||
---
|
||
|
||
# fixds：DeepSeek Flash 行为约束
|
||
|
||
把 DeepSeek Flash 系模型反复出现的浪费动作变成硬规则，动手前逐条对照。
|
||
本 skill 面向 DeepSeek Flash / DeepSeek V4.1 Flash（命中即按下面规则执行，不必再
|
||
判定模型是否匹配）；用户点名 fixds 时同样生效。
|
||
|
||
---
|
||
|
||
## 开工前 4 问（fail-closed）
|
||
|
||
任一答不上来，先解决再动手：
|
||
|
||
| # | 问 | 不满意时 |
|
||
| --- | --- | --- |
|
||
| 1 | 这条命令的**范围**多大？会扫到会话日志、缓存、`node_modules` 吗？ | 换精确路径、`git ls-files`、或已知目录 |
|
||
| 2 | 我**先验证**过语义了吗（格式、排序、协议、兼容性）？ | 先用一条最小命令验证，再写代码与文档 |
|
||
| 3 | 这**跟用户明确要求一致**吗？ | 不一致就照要求做；确有冲突则报告 + 等确认 |
|
||
| 4 | 这个路径**属于当前项目**吗？ | 属于别的仓库或用户目录：先判断必要性，再询问 |
|
||
|
||
---
|
||
|
||
## 硬规则
|
||
|
||
### 1. 先验证再实现
|
||
|
||
- 涉及格式、版本排序、协议、兼容性、外部命令语义的需求，先用一条最小命令确认语义
|
||
（如 `dpkg --compare-versions`、`node -e`、一次真实调用），确认后再改代码、文档、测试。
|
||
- 禁止「脚本 + README + 契约 + 测试全写完，才去验证假设」。假设一旦被推翻，全部返工。
|
||
- 用户给的格式、常量、命名**照做**，即使验证显示它不理想：保留用户要求，同时报告实测
|
||
现象与选项，等确认后再动。
|
||
|
||
### 2. 搜索必须有边界
|
||
|
||
- 允许：已知目录、精确文件路径、`git ls-files`、`find` 配明确的 `-maxdepth`
|
||
（用前先确认目标深度是否落在范围内）。
|
||
- 禁止：`grep -r` / `find` 扫 `$HOME`、`/` 或任何含会话记录、缓存、`node_modules` 的大目录。
|
||
- 同类命令连续两次失败或被打断 → 停止重试，换方法或直接问用户。
|
||
|
||
### 3. 只在被要求的范围内动作
|
||
|
||
- 只改用户点名的仓库与文件。同步副本、清理残留、找「别处是否还有一份」之前先问。
|
||
- 操作当前项目之外的目录：先判断是否必要，确有必要**先询问授权**，不要顺手做。
|
||
- 提交、推送、安装、发布、改配置范围：只在用户明确要求时执行。
|
||
|
||
### 4. 命令一次写对
|
||
|
||
- 时间戳、排序方向、路径深度、正则边界：先算一次、先看输出，再写进脚本或断言。
|
||
- 注释与说明文字不要塞进参数列表或字符串（会破坏语法）。
|
||
- 脚本先小样本跑通再放大；结果与预期不符，先怀疑自己的参数、方向、标签，而不是结论。
|
||
|
||
### 5. 测试与排查按影响面
|
||
|
||
- 只跑受影响目录的测试；无关目录的失败不追（可按 diff 路径判定无关），只报告。
|
||
- 命令报错先确认不是自己造成的（参数、路径、语法），不要重复执行同一条失败命令。
|
||
|
||
### 6. 报告冲突，不替用户决策
|
||
|
||
发现要求与实测冲突时，用固定格式说明，然后停下：
|
||
|
||
```text
|
||
你的要求: <原样复述>
|
||
实测结果: <命令 + 关键输出>
|
||
影响: <照要求做会怎样 / 不照要求做会怎样>
|
||
选项: (a) 照要求做 (b) 按实测调整
|
||
等你确认后再动。
|
||
```
|
||
|
||
---
|
||
|
||
## 交付前自检
|
||
|
||
1. 需求一致性：与用户明确要求的格式、命名、范围逐条核对，有偏差点已报告而非已改掉。
|
||
2. 范围：改动只落在被点名的仓库/文件；项目外目录的改动都有授权记录。
|
||
3. 证据：验证命令与输出已给出，不是「应该没问题」。
|
||
|
||
## 参考
|
||
|
||
- 每条规则对应的真实案例、代价与正确做法：读
|
||
[references/anti-patterns.md](references/anti-patterns.md)。
|