回顾我最近 30 天的工作（不足 30 天则使用全部可用历史），识别出值得沉淀打包的重复性手动工作流。
按以下优先顺序使用可用证据：
- 最近的 Codex 会话和任务摘要。
- Codex Memories 和 rollout 摘要，用于发现跨会话重复出现的模式。
- Chronicle（如果已启用），用于发现 Codex 之外的重复工作。Chronicle 仅用于线索发现，重要细节尽量回到相关源系统中确认。
- 现有的 skills、custom agents 和自动化任务，以便复用或扩展已有资产，而不是重复造轮子。
广泛留意以下特征的工作：重复发生、耗时、易出错、上下文成本高，或能从固定流程中受益。涵盖编码、调研、写作、规划、沟通、运营、分析、个人事务等各类工作流。
只对满足以下条件的候选项采取行动：
- 至少出现过两次，或明显会再次发生且每次重复代价不小；
- 拥有稳定的输入、可重复的流程，以及明确的输出或停止条件；
- 能在速度、质量、一致性或可靠性方面带来实质性改进；
- 现有资产尚未充分覆盖。
选择最小够用的形式：
- Skill：可复用的工作流或操作手册（playbook）。
- Custom subagent（自定义子 agent）：边界清晰、适合委派的专家角色或调研任务。
- Automation（自动化）：定时或周期性的检查、报告、提醒或监控。
- Skip（跳过）：过于零散、模糊、敏感，或证据不足以打包的工作。
先列一份精炼的候选清单，包含：
- 重复出现的工作流
- 佐证与日期
- 频率 / 置信度
- 推荐形式：skill、subagent、automation、扩展现有资产，或跳过
- 为什么值得 / 为什么不值得创建
然后只创建那些高置信度且确实缺失的项。保持它们聚焦、实用、来源清晰、易于验证。不要创建凭空臆测的、相互重叠的，或边界过宽的资产。
最后总结：
- 你创建或扩展了哪些
- 你刻意跳过了哪些
- 哪些还需要更多证据才能打包
附原文链接：
https://x.com/reach_vb/status/2058538305872949490
4 个帖子 - 4 位参与者
来源: LinuxDo 最新话题查看原文