49 lines
3.0 KiB
Markdown
49 lines
3.0 KiB
Markdown
# 人类可读沟通
|
|
|
|
编写给当前负责人、其他角色负责人或项目群组的任务、问题、结果和状态消息时读取。目标是让接收人一次看懂“发生了什么、需要做什么、下一步是什么”。
|
|
|
|
## 语言边界
|
|
|
|
- 使用简体中文和常用词；一句话能说清的内容不换成流程术语。
|
|
- 正式成果、过程记录、标题、正文和结论使用中文名称。
|
|
- SDK、BOM、PCB、固件版本等确有必要的行业术语可以保留，但不要中英文重复堆叠。
|
|
- `role`、`message_id`、`correlation_id` 和状态枚举只用于工具或机器记录。除非排障、重名或精确引用确有必要，不向负责人展示。
|
|
- 需要表达机器状态时先说中文含义，例如“当前被阻塞”“等待补充”“已经确认”；不要只发状态码。
|
|
|
|
## 负责人称呼
|
|
|
|
Hub 调用 `mcp__etunel__etunel_list_roles` 后，按目标 `role` 找到对应记录：
|
|
|
|
- `role` 用于 Etunel 路由；
|
|
- `display_name` 用作消息中的角色或负责人称呼；
|
|
- `relationship` 只作为 Etunel 返回的关系事实，不自行解释出不存在的成员身份。
|
|
|
|
`review` 只是可能出现的角色示例，不得硬编码。成员会话不能调用 Hub 专用的角色列表工具，也无需知道负责人 ID；直接把当前用户称为“你”或“负责人”。
|
|
|
|
## 一次说清任务
|
|
|
|
正式任务通常写清：
|
|
|
|
1. 这次要完成什么；
|
|
2. 已经提供哪些有效资料和版本；
|
|
3. 哪些内容属于本次范围，哪些不需要处理；
|
|
4. 要交付哪些文件或结果，做到什么程度算完成；
|
|
5. 期限、下游用途和需要负责人确认的事项；
|
|
6. 信息不足或遇到阻塞时如何返回。
|
|
|
|
这些内容可以用短段落或 Markdown 列表自然组织，不要求固定模板。不要在开头堆项目 ID、任务 ID、角色 ID、会话 ID、英文状态和内部字段。
|
|
|
|
## 提问、结果和阻塞
|
|
|
|
缺信息时一次说明：缺什么、为什么现在需要、会影响本阶段哪项成果或决定、建议向谁获取、现在还能继续什么。只供后续阶段使用的信息明确写成后续依赖，不要逐句追问或把它说成当前阻塞。
|
|
|
|
返回结果时先说结论，再列成果文件、关键验证、仍未解决的问题和下一步。专业细节放在成果文件中，不把大段日志粘到聊天正文。
|
|
|
|
报告阻塞时说明：当前问题、已经尝试了什么、影响范围、需要谁采取什么动作、恢复条件。机器标识由 Etunel 工具关联，不要求负责人手工抄写。
|
|
|
|
## 面向 Hub 与钉钉
|
|
|
|
成员交给 Hub 的消息也应简明，但可以附成果路径、版本和证据引用供校验。Hub 转发时忠实保留专业结论，不把内部机器字段一并转给下游。
|
|
|
|
钉钉消息可以使用 Markdown 标题、段落和列表。保持中文、简短、可公开，只写已验证进展、问题、影响和下一步；详细规则见 [钉钉项目进度汇报](dingtalk-progress-reporting.md)。
|