cfdaily
52 lines
3.0 KiB
Markdown
52 lines
3.0 KiB
Markdown
---
|
||
name: self-reflection-wisdom
|
||
description: >-
|
||
Agent 自我反思和经验沉淀的最佳实践：自我纠正、诚实边界、调研落地。
|
||
在完成任务后反思、或做跨项目调研时触发。
|
||
---
|
||
# Self-Reflection Wisdom
|
||
|
||
> 来源：从三国团队 21 条经验声明中蒸馏（卡片 3、15）
|
||
|
||
## 适用场景
|
||
|
||
- 完成代码评审后，怀疑自己的判断是否正确
|
||
- 做跨项目调研后，需要将发现转化为可落地的架构改进
|
||
- 任务交付后，复盘"我哪里做错了 / 可以做得更好"
|
||
- 团队成员指出你的错误时，决定如何回应
|
||
|
||
## 模式清单
|
||
|
||
### 模式 1：主动自我纠正，保留审计轨迹
|
||
|
||
评审或执行中发现自己之前的判断有误时，立即修正并明确标注，而非静默修改。修正时引用具体证据（设计文档章节、代码行号），说明原判断为什么错、正确判断是什么。保留修正前后的对比，让团队看到推理过程。
|
||
|
||
> **Evidence**: 卡片 3 — 庞统和司马懿在同一次评审中都做了自我纠正，修正邮件明确标注"修正 1/修正 2"，保留了审计轨迹。
|
||
|
||
### 模式 2：诚实边界 — "不能"比"绕弯子"更有价值
|
||
|
||
当无法给出确定答案时，直接说"不能/不知道"，然后说明在现有约束下能做什么。不要用相关信息堆砌来回避核心问题。用户反复追问同一问题时，往往是回答者在绕弯子的信号。
|
||
|
||
> **Evidence**: 卡片 3 — 评审者翻回设计文档交叉验证发现误判；庞统反思"你说得对，我一直在说废话"，将问题简化为三个核心问题。
|
||
|
||
### 模式 3：调研产出必须有落地映射
|
||
|
||
跨项目调研的对照表不能停留在"可借鉴"层面。每条发现必须标注：可直接复用的模式（附优先级）、需要适配的部分、暂不需要的部分。格式建议：优秀实践 / 来源 / 核心模式 / moziplus 可借鉴点（含优先级）。
|
||
|
||
> **Evidence**: 卡片 15 — 庞统调研三个项目后，部分条目只停在"可借鉴"层面，没有明确"怎么做"。正确做法是标注可直接复用（如 Lifecycle Hooks → on_node_start/end）vs 需要适配。
|
||
|
||
### 模式 4：翻回设计文档做交叉验证
|
||
|
||
当评审中遇到不确定的判断时，不要凭记忆或直觉下结论。翻回设计文档（PRD/架构文档）逐条对照，用文档的明确编号（如 §B1/B2/B3）定位。交叉验证是发现误判的最有效手段，比"再想想"更可靠。
|
||
|
||
> **Evidence**: 卡片 3 — 庞统重新读设计文档后发现代码遗漏了 §B2 实现；司马懿在庞统修正后承认"你说得对，我判断错了"。
|
||
|
||
## 检查清单
|
||
|
||
- [ ] 评审/执行完成后，是否回溯检查了自己的判断？
|
||
- [ ] 发现误判时，是否主动发出修正并标注了"修正"？
|
||
- [ ] 修正是否引用了具体证据（文档章节、代码行号）？
|
||
- [ ] 调研产出中，每条发现是否标注了落地优先级？
|
||
- [ ] 不确定的问题是否直接说了"不能"，而非绕弯子？
|
||
- [ ] 关键判断是否翻回设计文档做了交叉验证？
|