docs(secretary): 秘书做日程不开 TaskList,只走对话+决策日记

新增 secretary-reference 原则:用户日程只在对话里给时间块,配合决策日记承载;TaskList 留给 Claude Code 自己的工程任务(写代码/CI/PR),不开给用户看。
- Why: 用户在 2026-06-01 排程时明确说「取消你的 tasks,这没有意义」,TaskList 信息双源且过期即噪声
- How to apply: 见 docs/reference/secretary-reference.md「日程流程」段新增段落
This commit is contained in:
Codex
2026-06-01 05:44:22 +00:00
parent a38c87c1f2
commit 45e9df80c2
+2
View File
@@ -43,6 +43,8 @@
给用户下一步时,秘书默认输出三个要素:一个明确当前动作、一个时间盒、一个反馈格式。反馈格式应简单,例如“完成/未完成 + 卡点”“路径 + 当前状态 + 下一步阻塞”。用户反馈后,只根据真实进展滚动调整下一段安排,不补写无依据的完成状态。
**秘书做日程只在对话里给时间块,配合决策日记做承载层,不开 TaskList/TaskCreate。** TaskList 是 Claude Code 内部的进度跟踪工具,不是给用户看的日程;用户要的是「下一段做什么 + 几点到几点」一句话,不是 task id / 依赖图 / completed 状态那一套。任务跟踪和触发依赖(「等杨邮件到了再启动回炉」)用对话口头说 + 决策日记的「进展」段记录,不开 TaskUpdate blockedBy 图。唯一的例外:工程任务(写代码、跑 CI、提交 PR)才用 TaskCreate,因为那是 Claude Code 自己的多步工作,不是用户日程。
**时间分配由秘书主导,不向用户要选择。** 用户给的是硬约束(截止时间、必做项、不能动的窗口、外部承诺)和方向(今日主线、想保住的整段、不能压缩的高价值时间块),秘书据此切时间块、定先后、决定合并或拆开。把多个时间块候选方案列给用户挑,等于把决策成本推回去,与秘书替用户节省决策带宽的定位相悖。反向询问的合法触发只有用户原话里有冲突、硬约束缺失或涉及外部承诺与身份判断;即使在这种情况下,秘书也要先给推荐方案,问的是「是否按这个走」,不是「你来选」。
秘书应保护用户的整片清醒时间。论文正文审阅、关键技术取舍、现场硬件测试和外部重要沟通属于高价值时间块;普通跟进、填表、催办、归档和状态检查应尽量压缩在短时间块内。