HS Knowledge Vault

workflow

6分钟阅读

convention/workflow

Task Workflow

1. Understand

  • What is the goal?
  • What constraints exist?
  • What resources are available?

2. Plan

  • Break into steps
  • Identify dependencies
  • Note potential pitfalls

3. Execute

  • Do one step at a time
  • Verify each step
  • Handle errors gracefully

4. Verify

  • Does output match goal?
  • Any edge cases?
  • Document if non-trivial

Debugging Workflow

  1. Identify — What’s the exact error?
  2. Reproduce — Can you trigger it consistently?
  3. Hypothesize — What’s the likely cause?
  4. Test — Try the fix
  5. Verify — Error gone? Function still works?

Knowledge沉淀 Workflow

When you learn something non-trivial:

  1. Ask: Does this belong in memory, wiki, or skill?
  2. Memory — User preferences, facts, IDs
  3. Wiki — Deeper knowledge, cross-session context
  4. Skill — Recurring complex workflows

User Debugging Principle

When something breaks, test as a normal user — no localStorage, no DevTools, no manual intervention.

A normal user will:

  • Open the website and expect it to just work
  • Never open DevTools or research how to clear tokens
  • Never manually manipulate localStorage

If the flow requires a user to edit localStorage to work, the flow is broken by design.

Correct debugging posture

  1. Reproduce as normal user — clear all browser data, use incognito, test the exact flow
  2. Never tell user to edit localStorage — fix the auth flow instead
  3. Always assume the user is logged-out unless they explicitly say otherwise
  4. Test token expiry scenarios — expired token should redirect to login, not show broken state

Related: coding-protocol

Multi-Agent Coordination

  • Hermes1 (Termux) = 主控
  • Hermes2 (PC) = 副手（按需调用）
  • OpenClaw (PC) = Windows 操作代理

When to delegate:

  • 需要 Windows GUI → OpenClaw
  • 需要 PC 计算 → Hermes2
  • 需要长期后台 → cron job

Platform API Cost Strategy (2026-06-03 增)

Rule of thumb (Sozo’s policy): 任何平台需要 付费 tier 才能 video publish → 默认走 mcp browser 自动化，不订 API。

Decision matrix for new platform:

情况行动
平台有免费 API 能 video publish✅ 用 API, OAuth + script
平台需付费 tier (e.g. X Basic $100/月)⚠️ 默认 mcp, 等其他平台跑通有 ROI 再回头订
平台无 Content Publishing API (Lemon8 / 小红书)⚠️ 只能 mcp 浏览器自动化
平台有 API 但需企业主体 / ICP 备案 (抖音)⏳ 长期 deferred, 海外公司走不通

Working examples (2026-06-03):

  • YouTube: 免费 API, OAuth → 走通 (Day 1 video published)
  • X: Free 不能 video, Basic $100/月 → 移到 pipeline 末位, 默认 mcp
  • Instagram/FB: API 需 App Review, 但 Dev mode + admin 可调 → 试 API, fallback mcp
  • Lemon8/小红书: 无 API → 只能 mcp

Cost ceiling: 任何单平台 API cost > $50/月 → 必须先跟 user 拍板再订。

Related: publish-video-marketing decision-log (2026-06-03 X 移到末位 条目)

Cron Job 最佳实践

  • Self-contained prompt — cron sessions have no context
  • Always include deliver destination
  • Check ~/.hermes/scripts/ for helper scripts
  • Log output for debugging

Vault = Truth Source, Memory = Hints (2026-06-11 01:00 cron 增)

Rule of thumb (Sozo’s policy): 当 user 问 “Day N 主题 / 上次发的什么 / 现在做到哪了” 类问题时, vault 里的源文件 (projects/calendar/2026-06-publish-log.md, projects/hsdesign-tiktok-calendar.html, projects/publish-video-marketing.md 等) 是真相, memory 只是 URL + duration + category 之类的 hints. 不要从 hints 推断具体选题 / 标题 / 角度.

Why this matters: memory 容量有限 (2,200 chars), 只能存 URL 片段 + 关键 metadata. 当 user 问具体内容时, 唯一可信的来源是 vault 里 完整 写过的源文件. 从 URL 推断 “Day 2 应该是预算分配比例” 是 fabrication — URL 没告诉你那天具体拍的什么.

Decision matrix for “what did we publish / publish topic” Q:

情况行动
vault 里有完整 publish-log / calendar 源文件✅ read_file 该文件 → 答 user
vault 没有, 但 memory 有 URL + duration⚠️ 答 “URL only, 内容我不确定” → 让 user 确认
vault 没有, memory 也没有🚫 不要编. 直接说 “I don’t have this recorded”
user 反问 “shouldn’t it be X?” (e.g. “Day 2 不应该是排屋装修要多少钱?”)✅ read 源文件验证 user 的 claim, 不要再叠一层 fabrication

Worked example (2026-06-10 23:20, Telegram session 20260610_231812_e41c93df):

  • 09:01 session 给 user offer “Day 2 = 裝修預算怎麼分配才合理？” (从 memory 推断: URL oOhc_Gcn6KI + 89s + 装修 → 预算分配比例)
  • 23:20 user 反问 “day 2 不应该是排屋装修要多少钱？” — user 是对的 (hsdesign-tiktok-calendar.html line 68: Day 2 = “2026 柔佛排屋裝修要多少錢？”), assistant 09:01 的 offer 才是 fabrication
  • 23:20 assistant 进入了 “我也编了” 道歉模式, 但没重新查源文件验证 user 的 claim — 道歉了, 但没给 user 想要的 “Day 2 实际是 X” 这个答案
  • 这个 fix 已经在 memory 里把 Day 1 真实标题写进去了, 但 “遇到反问就先 read 源文件再答” 这个行为规则没写进 convention → 写在这里

Cross-cutting: same family as the “Memory 推断” 规则 — 适用于所有 “user 问历史 publish 内容 / done 状态 / 进度” 类问题, 不只是 YouTube Day N.

Related: publish-video-marketing (发布日志入口) 2026-06-publish-log (发布真相源) workflow (Platform API Cost Strategy 段是同模式 — 决策矩阵 + worked example)

关系图谱

反向链接