34 lines
2.9 KiB
Markdown
34 lines
2.9 KiB
Markdown
# 000 理念
|
|
|
|
dsh-superagent 是一个框架，也是一种与 agent 协作的方式。它的核心原则：
|
|
|
|
**尽量少地占用人的注意力，尽量多地交付价值。**
|
|
|
|
项目的每一处都按它花费的注意力来评判。一条消息、一次通知、一个问题、一个设置、一个面板元素、一段文档，各自都要消耗某个人的注意力，各自都必须给出比这更多的价值，否则就删掉。
|
|
|
|
## agent 要遵守的
|
|
|
|
- **它只在被要求、或被写下的规则允许时才行动。** 只有直接面向 agent、且来自团队允许的人的请求才算数：允许名单上的人，或团队开放给请求的会话里的任何人。没人要求的工作需要团队写下的规则，并且以只记录 agent 本会做什么的模式开始。
|
|
- **它只在有人必须行动、或用得上结果时才说话。** 它确认一次请求，并说明它将做什么。干活期间保持安静。有结果、需要决定、或无法完成时再写。消息简短，发到提出请求的那个对话。
|
|
- **它一次只问一个具体问题，** 用结构化表单，让问题到达人那里，而不是埋在一长段报告里。
|
|
- **它按影响停下，不按费力程度。** 本地改动推进到可评审的结果为止。需要设计决定的改动停在一个清楚的问题上。
|
|
- **它如实汇报。** 草案标未完成，失败按失败报告，绝不为了少问一句而绕过限制。
|
|
|
|
## 设计要遵守的
|
|
|
|
- **概念少。** 设计里只有它的领域概念（例如 Source）和这些概念的具体实现（例如 GitHub 和 Feishu）。一个业务需求要么变成其中某个概念的属性，要么变成 agent 遵循的一段提示词。设计不为此新增概念。
|
|
- **设置少。** 当一个取值几乎适合所有团队时，用默认值代替设置。团队用语言描述的行为是提示词文本，不是设置。
|
|
- **面板只显示需要人的东西。** 它先列出等待人的事项。健康的状态不占空间。
|
|
- **文档按顺序读。** 每篇编号文档只建立在前几篇之上，读者永远不会遇到一个还没引入的概念。
|
|
|
|
## 责任
|
|
|
|
agent 以你们团队天天见到的账号发评论、开 pull request、给人发消息。它发出的每条消息都消耗你同事的注意力，你要为此负责。agent 能做得越多，操作者对团队就越要多留心：
|
|
|
|
- **从窄处开始。** 先用一份短的允许名单，主动工作只做记录。等 agent 本会做的事看起来对了，再放宽这两样。
|
|
- **往噪声更少的方向调。** agent 太吵时，把它的提示词改短、改严，或者暂停它。不要为了解释噪声而多发消息。
|
|
- **不要拿它堆产量。** 大批量 pull request、群发消息、刷出来的活儿，团队亏的比赚的多。
|
|
- **替它说的话负责。** 读 agent 以你的名义发的内容，发现不对就在提示词里纠正。
|
|
|
|
目标是恰好的帮助出现在恰好的时间，其余时间什么都不出现。
|