53 lines
3.9 KiB
Markdown
53 lines
3.9 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 消息可以把简短的事项说明放入可选 `context`，完整要求保留在正文。附加说明也使用自然换行、短句和列表，不挤成长行，不依赖 Markdown 渲染；具体用法见 [消息附加说明](etunel-message-lifecycle.md#消息附加说明)。
|
|
|
|
## 提问、结果和阻塞
|
|
|
|
缺信息时一次说明：缺什么、为什么现在需要、会影响本阶段哪项成果或决定、建议向谁获取、现在还能继续什么。只供后续阶段使用的信息明确写成后续依赖，不要逐句追问或把它说成当前阻塞。
|
|
|
|
返回结果时先说结论，再列成果文件、关键验证、仍未解决的问题和下一步。专业细节放在成果文件中，不把大段日志粘到聊天正文。
|
|
|
|
报告阻塞时说明：当前问题、已经尝试了什么、影响范围、需要谁采取什么动作、恢复条件。机器标识由 Etunel 工具关联，不要求负责人手工抄写。
|
|
|
|
涉及阶段决定或待处理事项时，一事一条：说明所属阶段、具体问题、需要谁决定什么或处理什么。列全本轮需要行动的事项；已确定的安排直接说明结果，保留原有范围、限制和完成状态，不用“收口”“闭环”等词代替具体动作，不把已决定写成已解决。
|
|
|
|
## 面向 Hub 与钉钉
|
|
|
|
成员交给 Hub 的消息也应简明，但可以附成果路径、版本和证据引用供校验。Hub 转发时忠实保留专业结论，不把内部机器字段一并转给下游。
|
|
|
|
钉钉标题显示项目当前阶段编号和名称，正文按“已确认的进展”“待办事项”“遗留”组织；确认、决定和处理动作按“事项名称：由谁做什么”列入待办，未解决问题及跟进安排列入遗留，并在各事项中 @ 已明确的真人处理人。保留条件、停止事项和工作范围，阶段启动不写成阶段完成或项目关闭；纯 Agent 工作直接写对应角色。保持中文、简短、可公开，只写已验证进展、问题、影响和下一步；详细规则见 [钉钉项目进度汇报](dingtalk-progress-reporting.md)。
|