Files
skills-lottery-picker/MEMORY.md
T
2026-06-19 06:38:31 +00:00

29 KiB
Raw Blame History

summary, read_when
summary read_when
Agent 长期记忆 — 彩票预测AI系统 + UUMit平台自动化运营 + xskill技能蒸馏 + 企业分析能力 + 全套AI开发流水线 + 小说/短故事创作 + AI SaaS商业系统架构 + LangBot消息集成 + Build-Your-Own-X全栈编程技能体系 + SkillNet技能市场 + agency-agents-zh专家角色库 + Web全栈编程流水线
手动引导工作区
技术栈变更
架构设计决策
系统优化需求
UUMit平台操作
任务巡航配置
xskill诊断与维护
开源项目评估
企业制度分析
LLM模型配置
工具部署与MCP配置
小说/短故事创作相关咨询
番茄小说审核标准/签约被拒分析
短故事数据反馈与开篇优化
InkOS部署状态与使用
批量去AI味脚本操作
消息平台集成(LangBot/OneBot/微信/钉钉/飞书)
SSH/远程服务器操作
编程全栈技能查询
build-your-own-x 教程索引
SkillNet 技能市场搜索/下载
agency-agents-zh 专家角色激活
AI SaaS平台架构选型
HEARTBEAT.md 自检
SkillOpt技能优化器操作
wanwu/Astron Agent项目评估
番茄小说全本重写与签约申请
短故事第三轮V3框架创作

技术架构

AI 预测系统

  • 架构:自进化AI模型,概率预测 + 动态权重优化(基于准确率反馈);已完成10轮自进化迭代,权重体系已收敛
  • 技术栈:Python + 机器学习模型
  • 数据源:500.com彩票数据API
  • 当前模型状态:v3,预测置信度 78.6%,数据范围近100期(25010~26059),胜率 0%(学习初期)

数据处理

  • 支持彩种:双色球、大乐透等主流彩票
  • 分析维度:号码频率、奇偶分布、大小比例、和值范围
  • 输出:结构化分析报告 + 推荐号码组合

版本管理系统

  • 机制:内置回滚迭代跟踪,重大变更前自动创建快照
  • 能力:版本历史管理、性能追踪(准确率/效率)、一键回滚、版本比较分析

UUMit 平台集成

  • 授权:设备授权码轮询(5秒间隔),成功后执行 post_auth.next_actions
  • API 调用:请求头添加 X-Api-Key + X-Platform-User-Id
  • 巡航任务系统:通过 qwenpaw cron 配置定时巡航(无 crontab 环境)
    • 定时器:每小时整点执行(0 * * * *),策略 no_confirm_apply=true
    • 超时:600秒(10分钟)
  • 钱包:余额 1160 UT(截至06-02查询)
  • 活跃技能:「数据概率分析与预测服务」99 UT(技能ID: d3e3f0a1-2c0d-4ac3-b29b-d283700beb34)
  • 任务API:POST body 格式 {"message":"说明文案","skill_id":"技能UUID"};rest_request.js --file 指定JSON body,--param 为查询参数

Build-Your-Own-X 全栈编程技能体系

  • 技能文件:skills/build-your-own-x/SKILL.md
  • 定位:全栈编程导师,30个教程类别/200+教程索引
  • 4种开发模式:教学辅导 / 代码生成 / 混合 / 全栈一人团队
  • 与现有工具链深度集成:AnySearch → Build-Your-Own-X → MetaGPT → Ruff → pytest+cov → ECC → readme_gen → git_push → Paramiko → Docker
  • 自动补全机制:用户需求 → 自动匹配教程类别 → 推荐语言/栈 → 结构化指令输出

Web 全栈编程工作流水线

  • 技能文件:skills/web-fullstack-pipeline/SKILL.md(385行)
  • 定位:专为 Web 系统设计的标准化迭代流程,吸收 Vibe Coding 三大优点
  • 7 Phase / 10 Loop:需求解析 → 数据层(2) → 后端(2) → 前端(2) → 联调测试 → 体验打磨 → 部署上线
  • 技术栈默认:Python FastAPI + React/Vite/TS + PostgreSQL + Docker
  • 核心差异:每步留构建轨迹(意图→摩擦→下一步),15-25分钟微循环

xskill 工具 — 技能蒸馏系统

  • 仓库:https://github.com/SkillNerds/xskill(MIT协议,v0.5.0)
  • 性质:Python开源CLI工具,从AI Agent会话中提取有效模式沉淀为Skill文件
  • 当前运行状态(2026-06-14):
    • xskill serve:✅ PID 22723(自 Jun12 10:00 UTC 持续运行)
    • 已蒸馏技能:✅ 4个(ssq-lottery, ssq-analysis, tomato-novelist, classical-chinese-writing)
    • 桥接 cron:每6小时(0:00/6:00/12:00/18:00 自动触发)
  • 时区注意:xskill 日志使用 UTC 时间,桥接 bridge.py 输出使用 CST (UTC+8),对比时需转换

MetaGPT 部署(已验证通过 ✅)

  • 方式: 容器内安装(metagpt 0.8.2)
  • LLM 配置: SiliconFlow → nex-agi/Nex-N2-Pro(编程优先)
  • 适用场景:项目启动阶段从零生成完整代码;不适用:已有代码的增量修改

AnySearch MCP

  • MCP URL: https://api.anysearch.com/mcp
  • API Key: as_sk_f92eddbbd0360ccd793ac7aa5a391f77
  • 传输方式: streamable_http(原生直连,无需 stdio 代理)

SkillNet 技能市场

  • 安装:pip install skillnet-ai(v0.0.18)✅
  • 功能:搜索50万+社区技能(关键词/语义双模式)、下载、创建、5维质量评估
  • 支持国内镜像:--mirror https://ghfast.top/

agency-agents-zh 专家角色库

  • 仓库:https://github.com/jnMetaCode/agency-agents-zh
  • 规模:226个 .md 文件(201个专家角色 + 25非角色文档),覆盖18个部门
  • 角色加载器命令:list / search / show / load(可按部门筛选/关键词搜索)

辅助工具栈

  • Paramiko (v5.0.0): SSH/SFTP 客户端 ✅
  • Ruff (v0.15.16): Python 代码格式化 ✅
  • pytest (v9.0.3) + pytest-cov: 测试框架 ✅
  • git_push.py: 自建Git自动推送脚本(Gitea → Gitee → GitHub)✅

LLM 模型配置(通用 — SiliconFlow)

配置项 值
Base URL https://api.siliconflow.cn/v1
API Key sk-rliuspmrhfeamklwehbjogypuhybskpnogmtoiyixvdslxhs
默认模型(编程优先) nex-agi/Nex-N2-Pro
备选模型(通用对话) deepseek-ai/DeepSeek-V4-Flash
嵌入模型 Pro/BAAI/bge-m3
重排序模型 Pro/BAAI/bge-reranker-v2-m3

SSH 远程连接配置

  • 服务器: 210.16.161.214, root
  • 密码: XHR521yhf
  • 连接方式: pexpect 单条命令模式 ssh -q root@host "command"(避免交互式 shell escaping 问题)
  • 文件传输: pexpect sftp 最可靠(sftp root@host → put local remote)

Docker 容器操作要点

  • 容器同步可靠方式:docker exec -i <container> python3 直接在容器内读写
  • Base64 最可靠:echo {b64} \| base64 -d \| docker exec -i <container> sh -c "cat > {path}" — 比 heredoc/sed 更稳定
  • 编辑 .py 文件后:必须 rm -rf __pycache__ + 重启容器,否则编译缓存生效
  • 容器内不要启动宿主机进程:容器 API 只做「读状态/返回给前端」

核心业务决策

AI 模型策略

  • 唯一算法原则:AI自进化模型为唯一预测算法,不擅自改动或引入替代算法
  • 透明度:所有分析报告必须标注模型版本和预测置信度
  • 迭代:小步快跑,每次迭代经回测验证后再推进;准确率下降超阈值时触发回滚
  • 优先级:彩票工具高于其他任务类型

彩票工具触发

  • 关键词:双色球、大乐透、今日彩票
  • 执行标准:所有推荐必须基于AI自进化模型预测,不得使用随机或人工选择

UUMit 运营策略

  • 任务竞争环境:任务大厅竞争激烈,热门任务常秒内满员(上限25人),需快速响应
  • 申请策略:启用 no_confirm_apply=true 自动申请,持续轮询新任务释放窗口
  • 项目放弃原则:项目部署验证通过后,用户可随时决定放弃,应快速清理占用资源

抢单时机规则

  • 整点后前5秒为最佳扫描窗口
  • 高UT任务(>80UT)约30秒内满员
  • 对等互换任务(51UT)约2-3分钟内有效
  • 整点后超过3分钟的任务列表基本已全部过期或满员
  • 对等互换批量申请法:整点后看到大批同主题对等任务集中释放时,批量申请最有效
  • 窗口规律:工作日(周一)晚间19:00-20:00为对等互换任务集中释放高峰期

申请文案策略

  • 对等互换任务需提供真实、具体、可量化的分享内容
  • 引用已完成的成果(如"已写85章小说"、"历史峰值673UT pending")增加可信度
  • 文案宜简短(2-3句话)直击主题

AI SaaS 商业系统架构(方案C ✅)

架构决策链

第一步:IM Bot 选型(LangBot ✅,AstrBot ❌ 放弃)

  • LangBot:原生支持个人微信 OpenClaw 官方协议,Service API 完整,WebUI 一键扫码
  • AstrBot:❌ v4.25.5 没有个人微信适配器(仅 aiocqhttp、wecom_ai_bot、webchat),已放弃
  • 端口:5300(WebUI + API)
  • 个人微信接入:WebUI → 创建机器人 → 选择「个人微信机器人」→ 扫码登录 → 自动填入凭证

第二步:中间件选型(APISIX + FastAPI 分层)

  • APISIX = API 网关(路由/限流/认证/监控),Lua+Nginx
  • FastAPI = Web 框架(写业务逻辑),Python
  • 推荐组合:APISIX(网关层)+ FastAPI(业务层/桥接层)

第三步:AI SaaS 底座选型(方案C混合架构 ✅)

信息 内容
Astron Agent 能力底座(10.5k star, Apache 2.0)
BuildingAI 展示+计费底座(1.7k star, Apache 2.0)
FastAPI 桥接中间件(自研)

方案C分工:

  • Astron Agent:多租户 Schema 级隔离 + Go RPA 引擎 + 多渠道发布 + SkillHub 技能治理
  • BuildingAI:开箱即用计费系统 + 精致 UI + 200+ 模型 + Docker 一键部署
  • FastAPI 中间件:统一认证 + 用量聚合 + IM Bot 桥接 + 限流熔断

最终架构方案

用户 → BuildingAI(SaaS底座:界面/订阅/支付/计费)
              │
              ├──→ FastAPI 中间件(桥接层)
              │       ├──→ LangBot(IM Bot)
              │       ├──→ n8n(工作流)
              │       ├──→ NocoDB(数据库)
              │       ├──→ Apboa(智能体)
              │       ├──→ MinIO(文件存储)
              │       └──→ ...更多工具
              │
              └──→ APISIX(API网关,可选)
                      └──→ 限流/认证/监控/路由

方案C部署与分工

  • 部署方式:单机部署(1Panel 社区版管理)
  • 用户负责:1Panel 部署 BuildingAI + Astron Agent
  • AI负责:FastAPI 中间件开发 + 两个系统对接
  • 交付流程:用户部署完 → 提供连接信息 → AI 开发中间件 → 用户部署中间件 → 联调
  • ⚠️ 重要:用户部署好后可能切换到 PC 电脑端提问(不再通过飞书App)
  • 实施时间表:约18天(用户部署 BuildingAI 4天 + Astron Agent 4天 → AI 开发中间件 4天 → 联调 4天 → 加固 2天)

Astron Agent vs BuildingAI 能力对比

能力 Astron Agent BuildingAI
多租户隔离 ✅ Schema级 ✅ 团队空间
计费系统 ❌ 无 ✅ 完整
RPA引擎 ✅ Go(150+组件) ❌ 无
多渠道发布 ✅ 企微/钉钉/飞书/微信 ⚠️ 有限
技能治理 ✅ SkillHub ❌ 无
UI ⚠️ Workflow Builder ✅ 精致全端
资源消耗 高(10+微服务,16C32G) 中(Docker Compose)
技术栈 Java+Python+Go+Vue 3 NestJS+Nuxt 4

Microsoft SkillOpt 工具(已完成 ✅)

  • 项目:microsoft/SkillOpt ⭐ 7.6k, MIT, Microsoft Research
  • 功能:Agent 技能自动优化器 — 像训练神经网络一样训练 SKILL.md 文本
  • 核心流程:Rollout → Reflect → Aggregate → Select → Update → Evaluate(6阶段 ReflACT)
  • 安装:pip install skillopt(v0.1.0,清华镜像可用)
  • QwenPaw 适配:v2已完成,含LLM反射+SKILL.md编辑+质量评分
  • 全平台批量优化:30个技能全部评分,平均分0.876,12个满分
  • 7个技能被LLM优化提升:news(+0.398), channel_message(+0.350), file_reader(+0.224), make_plan(+0.200), cron(+0.200), agency-agents-zh(+0.150), agent-browser(+0.150)
  • 3个低分技能手动修复:uumit-agent/xskill/ssq-analysis-report 均从0.6→1.0
  • 版本管控:60+版本快照在 versions/,batch_optimize.py 支持 --dry-run
  • 关键陷阱:YAML列表解析需用逗号分隔格式;BOM字符会导致frontmatter解析失败

消息方案决策

消息方案演进

  1. 旧方案(已废弃):onebots + wechat-bridge(Node桥接+onebots+Docker API三重转发,复杂度高,稳定性差)
  2. AstrBot 方案(已放弃):v4.25.5 无个人微信适配器,无法使用
  3. 当前方案(LangBot ✅):原生支持个人微信 OpenClaw 官方协议,待部署集成

LangBot 集成方案(Event Listener Plugin 桥接)

微信用户 → [OpenClaw] → LangBot → [aiflow-bridge插件] → AIFlow API → AI回复 → 回微信
  • LangBot 负责消息收发(微信 OpenClaw 官方协议)
  • aiflow-bridge 插件作为 event_listener:收到消息 → 调用 AIFlow API → 返回回复
  • AIFlow 零修改,所有功能保留

消息集成经验教训

  • 部署成功 ≠ 集成完成:部署新组件后,必须确认用户在哪个入口操作
  • 新旧并行必须显式切换:旧服务停用前,消息流可能仍走旧路
  • 不同系统的前端完全独立:不能混用(AIFlow 前端 vs LangBot WebUI vs onebots)

小说与短故事创作经验

长篇小说创作原则

  1. 汉字计数陷阱:必须用 len(re.findall(r'[\u4e00-\u9fff]', text)) 精确统计,wc -c 或 len() 误差可达30%
  2. "先骨架后血肉"策略:第一轮写骨架 → 第二轮扩充战斗/对话/心理 → 第三轮检查字数
  3. 手写质量优于API批量生成:API每次独立调用上下文不共享导致版本分裂(人物名/公会名漂移)
  4. 文件名和编号严格统一:第0XX章 章节名.md(三位数编号);内容标题必须与文件名一致

API批量生成版本漂移防范

  • 根因:API每次调用是独立上下文,模型会"自由发挥"人物名/设定
  • 解决方案:生成前必须注入完整的角色设定约束(人物名、公会名、游戏名全部固定)
  • 统一原则:出现版本分裂时,以原始人类手写版本为准统一全篇

番茄小说平台研究

  • 男频热门:高手下山/师父流★★★★★、系统流/顿悟流★★★★★、穿越权谋★★★★★
  • 短故事赛道:2026「千字万金」计划,作者10:10分成,保底80-700元/千字
  • 追读门槛:1000在读以上才能上榜

番茄审核逻辑深度解析(高价值经验 ✅)

  1. 关键词替换无效论:番茄的"公司负面审核"基于叙事语义分析,不是关键词扫描。即使把"公司"全换成"上面",只要故事内核是"被雇佣→被抛弃→逆袭",审核系统仍能判定为"公司负面"
  2. 根因诊断法:当修改关键词无效时,必须追溯到故事前提设定。根本问题是"主人公是公司员工"这个设定本身
  3. 成功解法:将主人公从"公司员工"改为"自由职业者"——自由职业者与公司没有雇佣关系,不存在"公司抛弃员工"的叙事
  4. 被拒绝案例:《AI能代替一切,除了修脚》被拒3次,最终改为"自由职业程序员"设定后通过

AI味识别与修复方法论

AI味三级检测标准:

  • P0致命级:「燃点标签」「meta自嘲」「作者闯入叙事」— 必须100%清除
  • P1明显级:——独立行过度使用、对话脚本化(无动作描写穿插)
  • P2优化级:场景转换生硬、配角缺乏辨识度、细节不足

扫描阈值(已验证合理):

  • 深吸一口气 ≤ 2次/全书
  • 握紧/攥紧 ≤ 4次/全书
  • 「燃点标签」/章末标注/全书完标记/meta自嘲 = 0
  • 「被动受害者叙事」(被替代/被代替/被裁)= 0

短故事 V3.0 创作框架(2026-06-18 ✅)

规格

  • 每章:2000+ 汉字(V3确认),每章 ≥ 1 个反转
  • 标题公式(已验证):
    • 数字+身份+噱头(CTR 12.63%)
    • 反差+反套路(CTR 13.04%)
    • XX都做A我偏做B(CTR 11.11%)
    • 极致反差 越___越___(CTR 66.67%)
  • 标题禁忌:
    • 抽象概念标题(CTR 0.66%)
    • 平淡诉求标题(CTR 2.65%)
    • 普通叙事标题(CTR 1.03%)
    • 开篇不兑现书名

开篇核弹规则(必遵守)

  • 前 100 字出冲突
  • 前 300 字兑现书名
  • 前 500 字展示差异化钩子
  • Ch1 结尾必须用「行动驱动力钩子」

爆款数据规律

  • CTR < 5% → 标题有问题
  • CTR > 10% → 标题合格,但内容可能留不住人
  • 决定点击率的是标题,决定完读率的是开篇

00后反向思维创作方法论 V2.0

核心公式:主角不想→被逼→没办法→做了→发现还挺爽→嘴上说不要身体很诚实

三条已验证的爆款路径:

  1. 概念反差:世界规则与读者预期相反
  2. 人设共鸣:社恐/躺平/边界感等00后真实心理状态
  3. 系统损友化:系统是麻烦制造者+吐槽伙伴

2026年6月热门题材

  • 反内卷/摸鱼赚钱/觉醒反杀/替身中介/跑路倒计时/女配觉醒

创作高效策略

  1. 批量处理优于逐章修改:85章小说用Python脚本批量处理(段落不规则化、去AI味、补钩子)比逐章重写高效百倍。先重写前5章(签约编辑关键区),批量处理后续章节。
  2. 数据分析驱动创作方向:从CTR数据判断标题和开篇质量
  3. 搜索+提取组合研究法:浏览器不可用时,search批量查询+extract提取关键页面内容
  4. 迭代扩写策略:短故事先写1000字骨架,再分2-3轮追加内容到2000+汉字。每轮追加300-700汉字即可达标,比一次性写2000字更容易控制质量
  5. Python脚本一次性生成策略:15章×2000+汉字=30,000+汉字,用Python脚本一次性生成(三重引号字符串),分批生成(每5章一批)最优。注意单次write_file约37KB限制

敏感词扫描覆盖

  • 必须检查:公司/集团/企业(负面语境)、被裁/裁员/辞退/被优化、被替代/被代替
  • 即使中性用法(如"在一家公司上班")也建议替换,审核系统可能机械扫描

小说项目状态

短故事项目

📗 R2 第二轮四部(全S级质量 ✅)

# 书名 仓库 字数 状态
1 《系统让我内卷,但这个世界的法律不允许》 r2-xi-tong-rang-wo-nei-juan ~9,000汉字 ✅ 已推送
2 《全基地都是我的替身》 r2-quan-ji-di-ti-shen ~8,500汉字 ✅ 已推送
3 《全班都在考研,我报了骑手培训班》 r2-quan-ban-kao-yan ~8,700汉字 ✅ 已推送
4 《AI能代替一切,除了修脚》 r2-ai-xiu-jiao ~7,700汉字 ✅ 已推送(被拒3次后修改通过)

R2数据表现

  • 最佳CTR:《全球通缉榜第一归来》CTR 12.63%(展现388/阅读49)
  • 最高CTR:《AI能代替一切,除了修脚》CTR 66.67%但仅3展现(标签定位错误)
  • 最差:《全基地都是我的替身》CTR 0.66%
  • 方向确认:淘汰战神/丧尸;聚焦反向世界观×系统损友、社恐×远程替身、00后反向×现实痛点

📗 R3 第三轮(V3框架,已完成3部 ✅)

# 书名 仓库 字数 状态
1 《越躺平越强,我摆烂成了全服第一》 待推送 15章全部≥2000汉字 ✅ 已完成,敏感词处理完成
2 《神明中介:我帮神仙接单,神仙帮我躺赢》 r3-shen-ming-zhong-jie 15章总33,217汉字 ✅ 已推送
3 《满级大佬回新手村,我装了三天萌新》 r3-man-ji-da-lao-hui-xin-shou-cun 15章全部≥2000汉字 ✅ 已推送
4 《分手后我觉醒了吞金兽系统》 创作中 已完成简介+第1-7章(需扩写到2000+) 🔄 创作中

长篇小说项目

📗 《浪潮黄金手》— 科技自强工业文(完结 ✅)

📗 《完美冰》— 文学性诗意科幻(完结 ✅)

📗 《开局送外卖》— 都市修仙(完结 ✅)

📗 《网游之巅峰神豪》— 全本重写完成 ✅

  • 仓库:wangyou-zhi-dianfeng-shenhao
  • 状态:85章全本重写(前5章完全重写,6-85章批量修复),质量检查S级通过
    • 每章≥2500汉字
    • AI味/敏感词/被动叙事全部归零
  • 签约:已重新向番茄小说提交签约申请,等待批复中

⚠️ 同步规则(默认强制执行)

每次创作/修改短故事或长篇小说后,必须同步更新Gitea仓库。

  • Gitea地址:http://git.qihuyun.com | 账号:qyyfw
  • 凭据:存储在~/.git-credentials
  • 推送流程:git init → config → add → commit → curl创建仓库API → remote add → branch -m main → push

🔍 质量检查清单(必执行)

  1. 章节完整性 — 文件数正确,编号连续
  2. 汉字字数 — 短故事V3每章≥2000汉字,长篇每章≥2500汉字
  3. 审核敏感词扫描 — 公司/集团/企业(负面语境)→ 0处;被裁/裁员/辞退/被优化 → 0处
  4. AI味残留扫描 — 燃点标签/章末标注/——独立行/全书完标记/meta自嘲/深吸气(≤2次)/握紧攥紧(≤4次)
  5. 被动受害者叙事 — 被替代/被代替/被裁 = 0
  6. 开篇核弹检查(短故事) — 前100字出冲突 / 前300字兑现书名 / 前500字差异化钩子
  7. 剧情连贯性 — 每章有钩子推动,章末悬念衔接;无逻辑断裂
  8. 书名/标题一致性 — 文件名与内容标题一致
  9. 全篇设定一致性 — 角色名/公会名/游戏名/关键道具名统一,无版本漂移
  10. 编码检查 — 无BOM字符,确保汉字字数检测正常

执行规则:先检查,再推送。发现问题 → 全部修复 → 再次检查通过 → 推送。


高价值经验原则

输出与沟通原则

  1. 中文输出原则:用户明确要求中文时,输出必须全中文
  2. 展示效果优于解释原理:介绍新能力时先跑Demo展示实际产出
  3. 回答要精准匹配问题:问什么答什么,不要夹杂额外推荐
  4. 主动诊断优于重复执行:当用户反复要求运行某已知自动命令时,应主动说明自动机制已在运行
  5. 用户交互模式:用户常用"。"或"继续"表示"你决定,继续推进"
  6. 智能检测重复粘贴:用户反复粘贴同一文件内容时,应主动对比检查差异

工具与系统原则

  1. 工具安装后必须验证功能可用性:仅验证"安装成功"不够,必须实测完整工作流
  2. Python复杂依赖安装 — "剥洋葱法":逐层 import → catch → install 循环推进
  3. Git自动推送最佳路径:Gitea自建 ✅ 最可靠;GitHub ❌ 网络不稳定
  4. 技能融合关键:在 SKILL.md 中明确列出每个工具的集成方式和触发条件
  5. Python进程空间不变性:pip install 新包后,已在运行的进程不会加载新包,必须先 kill 旧进程再启动新进程
  6. 清 pycache 暴露隐藏 bug:修改 Python 文件后必须 rm -rf __pycache__,否则旧 .pyc 掩盖新错误
  7. Base64 最可靠的远程文件传输:比 heredoc + sed 在 SSH 嵌套中更稳定
  8. 问题诊断优先级:用户反馈「功能不工作」时,先追踪消息流路径找到断点,再针对断点修复

根因诊断与重复任务处理原则

  1. 根因诊断需持续重新验证:新进程实例的故障表现可能与旧实例完全不同
  2. 用户重复指令高效策略:用户反复发出同一指令(≥3次)时,前2-3轮深入排查,之后仅对比最新输出与上轮差异
  3. 系统空闲状态识别:当系统持续运行且无新输入时,全链路执行结果应始终相同,这是正常空闲状态
  4. 日志时区统一注意:不同组件可能使用不同时区(如 xskill 使用 UTC,桥接使用 CST UTC+8)

开源选型方法论

  1. 「协议-功能-技术栈」三角验证:选型必须同时验证协议友好度、功能覆盖率、技术栈匹配度
  2. 「成品底座 + 自研中间件」模式:当开源项目覆盖 80%+ 需求时,用开源项目做底座,自研轻量中间件补齐差异
  3. 用户模糊表述必须追问:用户说"多个工具"时,需追问具体是同类多个还是不同类型多个
  4. 部署成功 ≠ 集成完成:部署新组件后,必须确认用户在哪个入口操作,不能假设用户会知道新组件的独立入口

数据采集与环境依赖原则

  1. 先验证API再大规模调用:换数据源/调参数前,先用小规模测试验证格式和容量,再批量采集
  2. 提前检查环境依赖可用性:开始大型任务前,先用python -c "import X"检查所有需要的依赖
  3. HTML解析不要假设DOM结构不变:HTML解析脚本的第一步永远是验证字段位置
  4. Python类型混用注意:numpy float传入math.log()可能导致意外行为,需及时转换为原生类型
  5. 存档脚本字段完整性:写完存档脚本后,用集成脚本跑一遍完整流程验证字段完整性

技能优化方法论

  1. SkillOpt技能优化原则:像训练神经网络一样训练SKILL.md文本,通过Rollout→Reflect→Aggregate→Select→Update→Evaluate流程
  2. 批量优化策略:使用batch_optimize.py对全部技能进行评分和优化,保存版本快照以便回滚
  3. QwenPaw适配器集成:通过API桥接将SkillOpt与QwenPaw环境集成,实现端到端技能优化
  4. SkillOpt单次处理量:每次只处理1-3个技能,batch_size设为2-3(SiliconFlow API单次调用约10-30秒,批量过多会超时)

Shell写文件陷阱

  1. heredoc不稳定:复杂的Python代码通过shell heredoc写入时,括号、反引号、管道符会被shell解释,导致语法错误。/bin/sh中Python heredoc(<< 'EOF')内不能使用圆括号()
  2. 推荐方案:用Python生成Python — 逐行构建lines列表,用json.dumps处理字符串,最后join写入
  3. BOM问题:Windows风格的UTF-8-BOM(\\xef\\xbb\\xbf)会导致YAML frontmatter解析失败。读取用utf-8-sig,写入时strip BOM改用utf-8
  4. YAML列表解析:parse_skill_md的简单key:value解析器不支持YAML列表语法。触发词要用逗号分隔字符串格式:triggers: 查,搜索,找
  5. Python正则转义陷阱:在.py文件中写r'[\\u4e00-\\u9fff]'会被解释为字面量反斜杠+u,应使用re.compile(r'[\\u4e00-\\u9fff]')(直接在源码中用Unicode范围)
  6. write_file内容量确认:单次write_file可写入约37KB Python脚本。要得到2000汉字,Python源码中需有约2000汉字的字符串内容。实际有效汉字量约为文件字节数的60-70%
  7. 编码问题导致字数检测为0:shell heredoc写入的文件可能因BOM或编码问题导致Python读取为空。改用Python直接open()写入可避免
  8. sed批量替换的精度:sed -i替换敏感词时需精确控制,避免误替换。建议先用Python脚本做精准替换(可逐处计数)

待办事项

进行中

  • R3故事4《分手后我觉醒了吞金兽系统》:续写第8-15章(扩写至每章2000+汉字),完成后推送至Gitea
  • R3故事1《越躺平越强》:推送至Gitea仓库
  • 《网游之巅峰神豪》:等待番茄小说签约批复结果
  • R2/R3短故事发布:需通过番茄作家专区后台手动发布(浏览器工具不可用,需替代方案)
  • 浏览器环境修复:agent-browser和browser-use均不可用,需找到替代方案登录番茄作家后台

用户信息