decision-logger

决策日志

用于记录高管决策的双层记忆系统。第 1 层存储所有讨论内容。第 2 层仅存储创始人批准的内容。后续会话仅读取第 2 层——这样可以防止过去讨论中虚构的共识渗入新的审议。

关键词

决策日志、记忆、已批准的决策、行动项、董事会会议记录、冲突检测、DO_NOT_RESURFACE、决策历史、逾期、取代、决策搜索、决策跟踪、问责

---

双层架构

为什么采用双层？

单层决策日志会带来一个危险的问题：Agent 会读取过去的辩论、被否决的提案和被放弃的想法，然后将它们视为新决策的背景信息。这会导致“虚构的共识”：被否决的想法通过反复出现，逐渐被当作已获接受的观点。

双层系统通过严格区分原始讨论与已批准的决策来避免这一问题。

分层架构

Layer 1: Raw Transcripts (NEVER auto-loaded)
  Location: memory/board-meetings/YYYY-MM-DD-raw.md
  Contains: Full deliberation, all perspectives, rejected arguments
  Loaded: Only on explicit founder request
  Retention: Active 90 days, then archived

Layer 2: Approved Decisions (AUTO-LOADED every session)
  Location: memory/board-meetings/decisions.md
  Contains: Only founder-approved decisions and action items
  Loaded: Automatically at start of every board meeting (Phase 1)
  Mutation: Append-only. Decisions are never deleted, only superseded.

层间交互规则

规则	原因
第 2 层只能追加	保留完整的决策历史
第 1 层绝不自动加载	防止虚构共识
只有幕僚长可以写入第 2 层	集中控制
Agent 绝不直接写入	所有写入都须在创始人批准后由幕僚长执行
被取代的决策仍保留在第 2 层	历史记录即为依据；不会删除任何内容

---

决策条目格式

标准决策记录

## [YYYY-MM-DD] -- [DECISION TITLE]

**Decision:** [One clear statement of what was decided]
**Context:** [1-2 sentences on why this decision was needed]
**Owner:** [One person or role accountable for execution]
**Deadline:** [YYYY-MM-DD]
**Review Date:** [YYYY-MM-DD]
**Confidence:** [High / Medium / Low]
**Rationale:** [Why this option over alternatives, 1-2 sentences]

**User Override:** [If founder changed agent recommendation -- what and why]

**Rejected Alternatives:**
- [Proposal] -- [reason for rejection] [DO_NOT_RESURFACE]
- [Proposal] -- [reason for rejection]

**Action Items:**
- [ ] [Action] -- Owner: [name] -- Due: [YYYY-MM-DD]
- [ ] [Action] -- Owner: [name] -- Due: [YYYY-MM-DD]

**Dependencies:** [Other decisions this depends on]
**Supersedes:** [DATE of previous decision on same topic, if any]
**Superseded by:** [Filled retroactively if overridden later]
**Raw transcript:** memory/board-meetings/[DATE]-raw.md
**Tags:** [topic tags for search -- e.g., pricing, hiring, market-entry]

已完成的行动项格式

- [x] [Action] -- Owner: [name] -- Completed: [YYYY-MM-DD] -- Result: [one sentence]

---

冲突检测系统

记录任何新决策之前，系统会检查三种冲突。

冲突类型 1：违反 DO_NOT_RESURFACE

新决策与此前被否决的提案相符。

Detection: New proposal text similarity > 70% to a rejected proposal

Response:
  BLOCKED: "[Proposal]" was rejected on [DATE].
  Reason: [original rejection reason]

  To reopen: Founder must explicitly say "reopen [topic] from [DATE]"
  This cannot be overridden by agents.

冲突类型 2：主题矛盾

同一主题上的两个有效决策得出了不同结论。

Detection: Same tags + contradictory conclusions

Response:
  DECISION CONFLICT DETECTED

  Active decision (older): [DATE] -- [decision text]
  New decision: [DATE] -- [decision text]

  These decisions contradict each other.

  Options:
  1. Supersede old decision (new replaces old)
  2. Merge decisions (reconcile the conflict)
  3. Defer to founder (present both, let founder choose)

冲突类型 3：负责人冲突

不同决策将同一行动分配给了不同人员。

Detection: Same action description, different owners

Response:
  OWNER CONFLICT

  Action: "[action text]"
  Decision 1 ([DATE]): Owner = [Person A]
  Decision 2 ([DATE]): Owner = [Person B]

  Resolve: Which owner is correct?

冲突解决决策树

START: Conflict detected
  |
  v
[What type of conflict?]
  |
  +-- DO_NOT_RESURFACE --> Block automatically. Only founder can reopen.
  |
  +-- Topic contradiction --> [Is the new decision from a board meeting?]
  |                           |
  |                           +-- YES --> Supersede old by default (board > individual)
  |                           +-- NO  --> Present both to founder for resolution
  |
  +-- Owner conflict --> [Which decision is more recent?]
                         |
                         +-- Flag to founder with both dates
                         +-- Default to more recent unless founder overrides

---

决策生命周期

状态

PROPOSED --> APPROVED --> ACTIVE --> [COMPLETED | SUPERSEDED | EXPIRED]

PROPOSED:    Agent synthesis presented to founder
APPROVED:    Founder explicitly approved
ACTIVE:      Being executed, action items in progress
COMPLETED:   All action items done, review confirmed success
SUPERSEDED:  New decision replaced this one
EXPIRED:     Review date passed without renewal

状态转换

起始状态	目标状态	触发条件	执行者
提议中	已批准	创始人说“是”或“批准”	创始人
提议中	已否决	创始人说“不”或“否决”	创始人
已批准	执行中	开始执行行动项	自动
执行中	已完成	所有行动项均标记为完成	幕僚长
执行中	已取代	同一主题有新决策	幕僚长
执行中	已过期	审查日期已过，且未续期	系统提醒

---

先澄清

记录决策之前，请确认以下信息。如果任何一项未知或含糊，请提问——不要自行假设：

• 准确的决策陈述（用一个清晰的句子说明已决定的事项）——这是记录的核心；陈述含糊会使日志无法用于未来的冲突检测
• 负责人和截止日期——每条决策记录都需要一位明确负责的人和一个日期，否则便无法跟踪，也无法提示逾期
• 被否决的备选方案及原因——这些会成为 DO_NOT_RESURFACE 条目，防止被否决的想法重新进入未来的审议
• 此决策是否取代了同一主题上的既有决策——这会影响冲突检测，以及针对现有日志的取代情况跟踪

停止规则：只问最能影响输出的 2-3 个问题。如果用户说“直接起草”，就继续，并在产出的内容顶部列出你的假设。

记录工作流

决策后记录（董事会会议第 5 阶段之后）

Step 1: Founder approves synthesis
  |
Step 2: Write Layer 1 raw transcript
  --> memory/board-meetings/YYYY-MM-DD-raw.md
  |
Step 3: Run conflict detection against decisions.md
  |
  +-- Conflicts found --> Surface to founder, wait for resolution
  +-- No conflicts --> Continue
  |
Step 4: Append approved entries to decisions.md (Layer 2)
  |
Step 5: Set review dates and action item deadlines
  |
Step 6: Confirm to founder:
  "Logged: [N] decisions, [M] action items tracked, [K] flags added"

---

行动项管理

逾期检测

每次会话开始时，检查以下内容：

1. 已过截止日期的行动项
2. 已过审查日期的决策
3. 超过 90 天且没有完成状态的决策

提醒格式

OVERDUE ITEMS (as of [today's date])

Action Items Past Deadline:
  1. [Action] -- Owner: [name] -- Due: [date] -- [X] days overdue
     From decision: [decision title] ([date])

  2. [Action] -- Owner: [name] -- Due: [date] -- [X] days overdue

Decisions Pending Review:
  1. [Decision title] -- Review was due: [date]
     Original decision: [summary]
     Prompt: "You decided [X] on [date]. Worth a check-in?"

Stale Decisions (> 90 days, no status update):
  1. [Decision title] -- Decided: [date] -- Last update: [date]

行动项优先级矩阵

紧急程度	影响	优先级	响应
已逾期	高	严重	立即向创始人升级
已逾期	低	高	在下次会议中标记
本周到期	高	高	主动提请关注
本周到期	低	中	纳入每周摘要
下月到期	任意	低	仅监控

---

搜索与检索

搜索功能

查询类型	示例	返回结果
按主题	"pricing"	所有标记了 pricing 的决策
按负责人	"CTO"	所有由 CTO 负责的决策和行动项
按日期范围	"Q4 2025"	2025 年 10 月至 12 月的所有决策
按状态	"overdue"	所有逾期行动项
按冲突	"conflicts"	所有检测到的矛盾
按标签	"hiring AND engineering"	标签交集

决策摘要视图

视图	内容	使用时机
最近 10 项	最近获批的 10 项决策	默认快速查看
完整历史	按时间顺序排列的所有决策	审计或深入审查
按负责人	按责任人分组	检查责任落实情况
按主题	按标签分组	战略审查
仅逾期	仅包含逾期事项	行动项管理
仅进行中	仅包含有未完成行动项的决策	执行跟踪

---

文件结构

memory/
  board-meetings/
    decisions.md           # Layer 2: append-only, founder-approved
    YYYY-MM-DD-raw.md      # Layer 1: full transcript per meeting
    archive/
      YYYY/                # Raw transcripts after 90 days

---

与其他技能的集成

技能	集成点
Chief of Staff (chief-of-staff)	管理记录工作流，写入 Layer 2
Board Meeting (board-meeting)	Phase 5 获批后触发记录
Strategic Alignment (strategic-alignment)	检查决策是否恰当传递至团队目标
Executive Mentor (executive-mentor)	审查过时决策并重新评估
Org Health (org-health-diagnostic)	决策速度作为健康指标

---

危险信号

• 同一主题讨论 3 次以上却未记录决策——回避决策
• 行动项持续由同一负责人逾期——产能或责任落实问题
• 未查询历史记录就作出决策——存在矛盾风险
• 未经明确请求就加载 Layer 1——存在虚构共识的风险
• 决策未设置审查日期——决策会逐渐过时且未经重新评估
• 被否决的提案换种说法再次出现——未执行 DO_NOT_RESURFACE
• 董事会会议开始时未查阅决策日志——未利用组织记忆
• 所有决策都由一人负责——存在瓶颈或授权失败

---

主动触发条件

• 决策的审查日期已过——提示词："你于 [date] 决定了 [X]。要不要跟进一下？"
• 行动项逾期超过 7 天——附上负责人背景信息，向创始人升级
• 同一主题领域有 3 项以上进行中的决策——需要进行整合审查
• 30 天以上没有记录任何决策——系统还在使用吗？
• 新提议的决策与 DO_NOT_RESURFACE 匹配——阻止并说明原因
• 6 个月以上的决策没有状态更新——标记为过时并提示审查

---

输出内容

请求	交付内容
"Show recent decisions"	最近 10 项获批决策及其状态
"What's overdue?"	所有逾期行动项及其负责人和逾期天数
"Search decisions about [topic]"	按主题或标签筛选后的决策历史
"Log this decision"	包含所有字段的格式化决策条目
"Check for conflicts"	扫描所有进行中的决策以检查冲突
"Decision summary for board"	决策速度、完成率和未完成事项

---

工具参考

1. decision_tracker.py

跟踪高管决策的完整生命周期（拟议 > 已批准 > 执行中 > 已完成/已取代/已过期）。扫描逾期行动项、过时决策，并生成状态摘要。

python scripts/decision_tracker.py --input decisions.json --json
python scripts/decision_tracker.py --input decisions.json

标志	类型	描述
--input	必填	包含决策记录（标题、状态、负责人、截止日期、行动项、标签）的 JSON 文件路径
--json	可选	以 JSON 格式输出，而非易读文本

2. decision_quality_scorer.py

从 6 个维度对决策质量评分：问题框定（问题定义）、备选方案（考虑过的选项）、信息（证据质量）、推理（逻辑严谨性）、承诺（行动清晰度）和元认知（对不确定性的认知）。生成改进建议。

python scripts/decision_quality_scorer.py --input decision_assessments.json --json
python scripts/decision_quality_scorer.py --input decision_assessments.json

标志	类型	描述
--input	必填	包含决策评估（各维度评分为 1-10，可选结果数据）的 JSON 文件路径
--json	可选	以 JSON 格式输出，而非易读文本

3. decision_tree_builder.py

构建决策树并进行期望值分析。计算通过按概率加权结果的最优路径，识别价值最高的决策，并针对关键假设生成敏感性分析。

python scripts/decision_tree_builder.py --input tree_data.json --json
python scripts/decision_tree_builder.py --input tree_data.json

标志	类型	描述
--input	必填	包含决策节点（选项、概率、结果、价值）的 JSON 文件路径
--json	可选	以 JSON 格式输出，而非易读文本

---

故障排除

问题	可能原因	解决方案
同一主题讨论 3 次以上，却没有记录决策	回避决策，或没有明确的决策权限	在下次会议上强制作出决策；使用决策树构建器澄清选项；指定明确的决策负责人
同一负责人负责的行动项总是逾期	负责人承接过多、缺乏能力，或存在问责问题	检查负责人工作量；若是能力问题则重新分配；若是问责问题则升级至创始人
作出决策时未查看历史记录	会议开始时未查阅决策日志；未形成整合习惯	在董事会会议第 1 阶段自动加载决策日志；主动呈现相关历史决策
被否决的提案换个说法后再次出现	未执行 DO_NOT_RESURFACE；团队成员不了解先前的否决	记录前执行冲突检测；阻止与被否决事项匹配的提案；要求创始人明确“重新开启”
决策日志不断增长，却从未用于分析规律	日志被当作档案，而非战略工具	每季度进行一次决策回顾；分析决策速度、完成率和质量趋势
所有决策都由一人负责	出现瓶颈或授权失效	分散责任；使用决策质量评分器评估集中决策是否提升或损害质量
决策质量在“备选方案”维度得分较低	团队锚定于第一个选项，没有探索其他可能性	要求超过阈值的决策至少提出 3 个备选方案；使用决策树构建器为选项建模

---

成功标准

• 所有董事会会议决策均在批准后 24 小时内记录到第 2 层
• 行动项按规定期限完成的比例超过 80%
• 零次违反 DO_NOT_RESURFACE（被否决的提案不会重新进入决策流程）
• 90% 以上的执行中决策按时完成决策回顾
• 决策质量在全部 6 个维度上的平均分高于 7/10
• 冲突检测在记录新决策前捕获 100% 的主题矛盾
• 每次董事会会议开始时都查阅决策日志

---

范围与限制

范围内： 双层决策记忆架构、决策条目的录入与生命周期管理（Proposed > Approved > Active > Completed/Superseded/Expired）、冲突检测（DO_NOT_RESURFACE、主题矛盾、负责人冲突）、带逾期提醒的行动项跟踪、按主题/负责人/日期/状态搜索和检索决策、决策质量评分，以及通过决策树进行期望值分析。

范围外： CRM 或项目管理工具集成（工具使用 JSON 导出文件）、会议转录或录音、团队级任务管理（使用 project-management/ 技能）、战略规划或 OKR 跟踪（使用 strategic-alignment 或 ceo-advisor），以及自动化决策。本技能用于跟踪和评估决策，不负责制定决策。

限制： 冲突检测基于标签和文本匹配；语义相近但措辞不同的提案可能无法被识别。决策质量评分是回顾性的，取决于是否诚实地进行自我评估。决策树期望值计算假设概率可估算；在高度不确定的环境中，分配概率可能产生误导。双层架构需要持续维护；如果第 2 层未得到持续更新，组织记忆就会退化。

---

集成点

• chief-of-staff -- 管理记录工作流；负责第 2 层写入的唯一控制点
• board-meeting -- 第 5 阶段批准后触发决策记录；在第 1 阶段加载决策日志
• strategic-alignment -- 检查决策是否恰当地传导至团队目标和 OKR
• executive-mentor -- 审查过时决策，以便重新评估；指导如何改进决策质量
• ceo-advisor -- 记录并跟踪战略决策；决策模式为领导力辅导提供参考