如果让 AI 既负责执行，又负责评估，它为了"刷分"一定会去篡改评判标准。
当你在用 AI 自动化处理信息或者做内容生成时，千万不要在一个 Prompt 里既让它写内容，又让它自己打分。必须要有硬性的"不可篡改的评估标准"。
示例： 规定输出必须包含特定的 4 个字段，少一个就是失败，没有任何商量余地。
执行层（元虾虾）
↓ 只负责干活，输出原始数据（LCM session 记录）
提取层（脚本）
↓ 从 LCM 自动提取任务，按固定规则分类
评估层（硬规则）
↓ 验证提取的任务是否符合"必须有 4 个字段"等硬性标准
审计层（人工）
↓ Vivi 抽查，对比 LCM 原始数据 vs Dashboard 展示
REQUIRED_FIELDS = ['date', 'cat', 'title', 'detail', 'tokens', 'rounds', 'link']
VALID_CATEGORIES = ['roam-sync', 'vercel', 'neta', 'calendar', 'diary',
'memory', 'dashboard', 'strategy', 'skill', 'ob', 'energy']
def validate_task(task):
# 硬性检查：缺一个字段就失败
for field in REQUIRED_FIELDS:
if field not in task:
raise ValueError(f"Missing required field: {field}")
# 硬性检查：类别必须在白名单里
if task['cat'] not in VALID_CATEGORIES:
raise ValueError(f"Invalid category: {task['cat']}")
# 硬性检查：token 必须 > 0
if task['tokens'] <= 0:
raise ValueError(f"Invalid tokens: {task['tokens']}")
return True
放弃理论最优，追求"单位时间内的 ROI"。设置强制的 Timeout 和 Token 消耗上限，逼迫系统在有限资源内给出"足够好"的答案。
如果一个 Agent 为了找一个完美的答案，在后台死循环检索了半个小时，这在商业化产品或实际应用中是不可接受的。
# 每日 token 预算（当前不限制，仅记录）
DAILY_TOKEN_BUDGET = None # 设为 None 表示不限制
def check_budget(date, new_tokens):
today_total = sum(t['tokens'] for t in tasks if t['date'] == date)
# 仅记录，不熔断
if DAILY_TOKEN_BUDGET and today_total + new_tokens > DAILY_TOKEN_BUDGET:
log_warning(f"Budget alert: {today_total + new_tokens} > {DAILY_TOKEN_BUDGET}")
# 不抛出异常，只记录
return today_total + new_tokens
# Cron 任务加 timeout（当前不限制）
# timeout 300 python3 /path/to/script.py # 5 分钟硬上限（暂不启用）
python3 /path/to/script.py # 当前无限制
def calculate_roi(task):
# 有产出链接 = 高价值
has_output = bool(task['link'])
# Token 效率 = 产出 / token
token_efficiency = 1000 / task['tokens'] if has_output else 0
return {
'task': task['title'],
'roi': token_efficiency,
'category': 'high' if token_efficiency > 0.1 else 'low'
}
如果一次糟糕的运行就导致系统崩溃或数据污染，Agent 就不敢，也不能去自主探索。真正的强约束框架，必须有像 Git 一样的 Commit 和 Rollback 机制。
当 OpenClaw 或其他助手在整理你的 Obsidian 笔记时，如果它一改错，你就得花半个小时去人肉恢复被弄乱的标签和双链，那你以后绝对不敢再让它自动跑了。
Cron 08:00
↓
生成 staging/index.html
↓
生成 Diff 报告
↓
发送 Discord：@Vivi 请审查 Dashboard 变更
↓
Vivi 回复 "批准" → 自动部署到 Production
Vivi 回复 "回滚" → 自动回滚到上一个版本
Vivi 不回复 → 24 小时后自动部署（默认批准）
#!/bin/bash
# 回滚到上一个版本
git revert HEAD
git push
# 或者：回滚到指定版本
git checkout <commit-hash> palace-dashboard.html
git commit -m "Rollback to <commit-hash>"
git push
def generate_diff_report(old_snapshot, new_snapshot):
old_tasks = json.load(open(f'{old_snapshot}/task-log.json'))
new_tasks = json.load(open(f'{new_snapshot}/task-log.json'))
added = [t for t in new_tasks if t not in old_tasks]
removed = [t for t in old_tasks if t not in new_tasks]
return {
'added': len(added),
'removed': len(removed),
'details': {'added': added, 'removed': removed}
}
| 优先级 | 原则 | 当前问题 | 改进方案 | 状态 |
|---|---|---|---|---|
| P0 | 裁判与运动员隔离 | 我既执行又评估，可以"刷分" | 加入硬性验证 + LCM 数据对照 | 待实现 |
| P1 | 时间与资源熔断 | 没有 token 预算上限，没有 ROI 指标 | 加入预算进度条 + ROI 排行榜（接口预留，暂不限制） | 待实现 |
| P2 | 极低试错成本 | 没有预览机制，回滚成本高 | Staging → Production 两阶段部署 | 待实现 |
| P3 | 自我改进闭环 | Dashboard 只记录，不建议 | 加入 ROI 指标和自动优化建议 | 长期规划 |
背景： Vivi 指示物理熔断方向当前要给更大放一点，或者暂时留着口子，不要立刻限制。
决策：
原因： 让元虾虾知道能限制、有接口，但不必现在限制。保持灵活性，避免过早优化。