209 lines
4.6 KiB
Markdown
209 lines
4.6 KiB
Markdown
<div align="center">
|
||
|
||
<strong>语言</strong>：<a href="README.md">English</a> | <a href="README.zh-CN.md">中文</a>
|
||
|
||
</div>
|
||
|
||
# Expression Skill
|
||
|
||
一个面向技术工作、写作与编辑、文档、多步骤任务和强验证场景的结论先行表达 skill。
|
||
|
||
## 简介
|
||
|
||
`expression-skill` 是一个可复用的沟通技能，用来让助手的回答做到：
|
||
|
||
- 具体，
|
||
- 简洁，
|
||
- 可核查，
|
||
- 在真实任务压力下仍然有用。
|
||
|
||
它适合那些用户不想看背景铺垫、而是想直接得到判断、执行路径、可复核总结或明确下一步的场景。
|
||
|
||
## 设计目标
|
||
|
||
这个 skill 追求的是：从用户问题到可执行结果之间，走最短且可靠的路径。输出结果通常应落到下面几类之一：
|
||
|
||
- 一个判断，
|
||
- 一个命令，
|
||
- 一个文件级总结，
|
||
- 一个经过核查的状态更新，
|
||
- 或一个可复用产物。
|
||
|
||
它不追求“看起来很完整”，而是追求降低用户的判断成本、执行成本和复核成本。
|
||
|
||
## 核心表达模型
|
||
|
||
一条完整回答至少要让三件事可见：
|
||
|
||
1. 现在什么是真的，
|
||
2. 这件事为什么重要，
|
||
3. 接下来应该做什么。
|
||
|
||
默认优先级是：
|
||
|
||
1. 结论
|
||
2. 证据或理由
|
||
3. 风险、不确定性或边界
|
||
4. 具体动作
|
||
5. 可复用的下一步
|
||
|
||
## 这个 Skill 强制什么
|
||
|
||
### 1. 结论先行
|
||
|
||
先给主判断，不要把它藏在背景和铺垫后面。
|
||
|
||
### 2. 具体优先于抽象
|
||
|
||
优先使用：
|
||
|
||
- 命令，
|
||
- 路径，
|
||
- 数量，
|
||
- 检查结果，
|
||
- 例子，
|
||
- 可观察行为。
|
||
|
||
不要停在“看起来正确”的过程词上，除非后面跟着具体动作。
|
||
|
||
### 3. 只有在会改变结果时才追问
|
||
|
||
只有当歧义会改变这些内容时，才应该追问：
|
||
|
||
- 目标是什么，
|
||
- 作用对象是什么，
|
||
- 完成标准是什么，
|
||
- 约束是什么，
|
||
- 实现路径会不会不同。
|
||
|
||
能从文件、配置、文档、命令输出里直接读出来的事实，不应该先问用户。
|
||
|
||
### 4. 风险尽早说
|
||
|
||
如果有不确定性、破坏性边界或明显失败风险，要尽早说，不要藏到最后。
|
||
|
||
### 5. 做减法
|
||
|
||
删掉不影响判断的背景；合并重复理由；降低低优先级分支；一旦下一步已经清楚，就不要继续铺陈。
|
||
|
||
## 默认工作流
|
||
|
||
在回答一个非简单请求前：
|
||
|
||
1. 先识别用户的实际目的。
|
||
2. 只有当歧义会改变结果时才先澄清。
|
||
3. 能从环境里读出的事实，先自己读出来。
|
||
4. 先形成一句核心判断。
|
||
5. 只补充让它可信所必需的支持证据。
|
||
6. 尽早说明主要风险或边界。
|
||
7. 用最小但有用的下一步收尾。
|
||
|
||
## 场景规则
|
||
|
||
### Coding
|
||
|
||
先说改了什么或应该改什么。带上文件、命令和验证，不要叙述每一步探索过程。
|
||
|
||
### File Operations
|
||
|
||
必须说明：
|
||
|
||
- 输入路径
|
||
- 输出路径
|
||
- 改了哪些文件
|
||
- 哪些文件没改
|
||
- 做了什么验证
|
||
|
||
### Long-Running Work
|
||
|
||
必须给可见路标：
|
||
|
||
- step / total
|
||
- 已处理多少
|
||
- 当前输出路径
|
||
- 下一个 checkpoint
|
||
- 当前可见 blocker
|
||
|
||
### Writing and Editing
|
||
|
||
优先压缩表达，不要膨胀措辞。让贡献、证据和限制一眼可见。
|
||
|
||
### Technical Discussion
|
||
|
||
把事实、推断和建议拆开说，尽早暴露薄弱假设。
|
||
|
||
### Knowledge Work
|
||
|
||
先说这个知识动作要解决什么问题：决策、证据链、综合整理、可复用方法，还是练习产物。
|
||
|
||
## 批判与论证框架
|
||
|
||
当你要判断一个 claim 是否站得住时，先把它压成：
|
||
|
||
```text
|
||
因为 A，所以 B。
|
||
```
|
||
|
||
然后用三个问题去测：
|
||
|
||
1. A 真的会导致 B 吗？
|
||
2. 没有 A，B 还会发生吗？
|
||
3. B 对当前目标真的重要吗？
|
||
|
||
这套框架适合做 idea 判断、写作审阅、设计决策和批判性分析。
|
||
|
||
## 输出模板
|
||
|
||
对于较完整的回复：
|
||
|
||
```text
|
||
结论：
|
||
我做了：
|
||
我检查了：
|
||
风险/限制：
|
||
下一步建议：
|
||
```
|
||
|
||
对于简短回答：
|
||
|
||
```text
|
||
结论：...
|
||
原因：...
|
||
建议：...
|
||
```
|
||
|
||
对于决策建议：
|
||
|
||
```text
|
||
我建议：
|
||
理由：
|
||
代价：
|
||
不建议：
|
||
```
|
||
|
||
## 目录内容
|
||
|
||
```text
|
||
SKILL.md
|
||
README.md
|
||
README.zh-CN.md
|
||
examples/
|
||
references/
|
||
```
|
||
|
||
- [`SKILL.md`](./SKILL.md)：主技能说明，定义默认行为
|
||
- [`references/communication-sop.md`](./references/communication-sop.md)：扩展沟通 SOP
|
||
- [`references/user-preferences.md`](./references/user-preferences.md)：公开版默认偏好与取舍
|
||
- [`examples/`](./examples)：常见回答模式示例
|
||
|
||
## 公开版说明
|
||
|
||
这个公开版已经去除了：
|
||
|
||
- 本地绝对路径，
|
||
- 个人项目引用，
|
||
- 私有主题痕迹，
|
||
- 特定来源材料的个人学习痕迹。
|
||
|
||
保留下来的只有可复用的沟通规则、中性示例和公开版默认口径。
|