22 KiB
22 KiB
多技能组合手册 — 小唯 A06（技能链 × 任务画像）
版本：1.0.0 | 2026-09-06 | kanban t_52c49737 · prof-b 一句话：单技能是一把刀，技能链是一条流水线。 本手册把 301 个 active 技能编排成「任务画像 → 技能链」组合，覆盖我们真实高频场景。 技能名全部在
~/.hermes/skills/磁盘真实存在（含 1 个符号链接 nuyoah-xiezhen-prompt → .agents/skills），可脚本验证。 用法：接到任务先对画像，命中就按链加载；每条链 2-4 个技能，跨 category 才叫组合。
第一部分 通用技能层（元技能）— 横切一切专业任务
牧尘 2026-09-06 指令：通用技能 = 横切所有专业任务的「思维/质量前提层」，独立成层。 本部分只列已存在的元技能（不编造）；执行任何专业任务时，按 §1.2 的叠加模式套用。
1.1 通用技能清单（按思维动作分组，全部真实存在）
| 思维动作 | 通用技能（元技能） | 真实路径 | 一句话 |
|---|---|---|---|
| 规划 | plan | software-development/plan | 写可执行 markdown 计划（Plan mode；顶层 LaunchDarkly 外部 plan 已归档 .archive/plan-launchdarkly） |
| 规划 | persistent-planning | persistent-planning/ | Manus 式持久化文件规划 |
| 规划 | writing-plans | software-development/writing-plans | 写可执行实现计划（bite-size 任务） |
| 规划 | kanban-orchestrator | devops/kanban-orchestrator | 分解 + 反诱惑规则 |
| 规划 | task-breakdown | projectManagerBreakout/skills/task-breakdown | 大模糊问题拆成精确任务树 |
| 规划 | sprint-planning | projectManagerBreakout/skills/sprint-planning | 排期/负载均衡 |
| 规划 | dependency-analysis | projectManagerBreakout/skills/dependency-analysis | 依赖图/瓶颈检测 |
| 三思/行动前验证 | systematic-debugging | software-development/systematic-debugging | 4 阶段根因调试（先懂后修） |
| 三思/行动前验证 | requesting-code-review | software-development/requesting-code-review | 提交前审查（安全/质量门/自动修） |
| 三思/行动前验证 | karpathy-code-discipline | karpathy-code-discipline/ | 代码纪律（最小化、诚实） |
| 三思/行动前验证 | lazy-senior-dev | software-development/lazy-senior-dev | 7 阶梯最小化决策 |
| 三思/行动前验证 | agent-feedback-control | autonomous-ai-agents/agent-feedback-control | PEV 反馈控制闭环 |
| 反思/复盘 | retro | product-management/retro | 结构化复盘 |
| 反思/复盘 | daily-recap | productivity/daily-recap | 每日复盘报告 |
| 反思/复盘 | weekly-review-planning | productivity/weekly-review-planning | 每周重置承诺/停滞/下周 |
| 反问/批判质疑 | strategy-red-team | product-management/strategy-red-team | 攻击方案假设（红队） |
| 反问/批判质疑 | pre-mortem | product-management/pre-mortem | 事前预演失败 |
| 反问/批判质疑 | merge-reconciler | autonomous-ai-agents/merge-reconciler | 中立第三方解决分歧 |
| 反问/批判质疑 | intended-vs-implemented | product-management/intended-vs-implemented | 找意图与实现的差 |
| 验收/完整性检查 | kanban-review-gate | autonomous-ai-agents/kanban-review-gate | PDCA 验收门禁（done≠完成） |
| 验收/完整性检查 | sdlc-review | devops/sdlc-review | 评审 Kanban 交接/路由验证 |
| 验收/完整性检查 | skill-curator-workflow | skill-curator-workflow/ | 技能 curator 审计流程 |
| 验收/完整性检查 | hermes-self-improvement | autonomous-ai-agents/hermes-self-improvement | 技能生命周期/质量标尺/删除规范 |
| 验收/完整性检查 | shipping-artifacts | product-management/shipping-artifacts | 交付物持久化文档集 |
| 验收/完整性检查 | dogfood | dogfood/ | 探索性 QA 找 bug |
| 验收/完整性检查 | website-ux-audit | productivity/website-ux-audit | 全站 UX/代码质量审计 |
| 通用流程入口 | team-composer | autonomous-ai-agents/team-composer | 144 skill + 184 ao 角色组队 |
| 通用流程入口 | project-toolbox | knowledge/project-toolbox | 项目工具箱总索引 |
| 记忆质量 | memory-routing-contract | knowledge/memory-routing-contract | 记忆路由矩阵 |
| 记忆质量 | memory-governance | knowledge/memory-governance | 注入预算/淘汰/分层 |
| 记忆质量 | memory-verification | zhiyi/memory-verification | 写入前事实校验 |
注：
software-development/plan是小唯自己的 Plan mode 元技能（写 .hermes/plans/ 可执行计划）。曾被误当作 LaunchDarkly 外部套件（顶层plan/0.2.0，2026-09-06 已归档至.archive/plan-launchdarkly）——真正做规划走persistent-planning+writing-plans+kanban-orchestrator。
1.2 专业技能 × 通用技能的叠加模式（万能模板）
一条完整专业任务 = 通用层(横切) × 专业层(领域)
① 规划层 persistent-planning / writing-plans / pre-mortem(高风险时) / task-breakdown
② 执行层 专业技能(该任务领域技能，如 KOCR/织忆/ComfyUI/公文/调研)
③ 三思/质疑 systematic-debugging(出错时) / strategy-red-team(方案重大时) / agent-feedback-control(迭代反馈)
④ 验收证据 kanban-review-gate(PDCA) / requesting-code-review(代码) / skill-curator-workflow(技能)
⑤ 复盘沉淀 retro / hermes-self-improvement(把模式存成技能) / daily-recap
实例：牧尘发来一批凭证 PDF → ① 规划：先想清批次/模板/合并规则（persistent-planning 落 /tmp 计划，防 gateway 重启失忆） ② 执行：accounting-voucher-ocr（KOCR v8 单 PDF → 金蝶 K3 Excel） ③ 三思：产出自检三关（摘要真实/科目干净/借贷平衡）——验收前置 ④ 验收：kanban-review-gate 过「运行证据」；发牧尘前自审 ⑤ 沉淀：新坑 → patch accounting-voucher-ocr skill
第二部分 任务画像 × 技能链（18 条高频画像）
规则：技能链按执行顺序写；每条注明各技能的真实 category；为什么单技能不够；组合后的 1+1>2。 命名 = 目录名（skills_list 可用名）。
C1. 竞品/行业调研报告（要交付一份可引用的分析）
| 步骤 | 技能 | category |
|---|---|---|
| 1 | competitor-news-monitor（持续盯目标公司新闻，带引用摘要） | research |
| 2 | web-content-extraction / scrapling（crawl4ai/scrapy/stealth 抓正文） | productivity / research |
| 3 | grounded-citations（每条论断钉住可验证来源） | research |
| 4 | team-composer（需要时并行多角色：研究员→分析师→摘要师） | autonomous-ai-agents |
- 为什么单技能不够：competitor-news-monitor 给「发生了什么」但抓不到深页正文；光抓取没有引用纪律 = 报告不可信；没有编排 = 所有维度自己串行跑。
- 1+1>2：监控器喂素材 → 抓取补全文 → grounded-citations 强制带出处 → team-composer 并行拆维度，产出从「资讯堆」变成「可验证调研报告」。
C2. 正式公文写作（请示/通知/函/总结，要合规+像人写的）
| 步骤 | 技能 | category |
|---|---|---|
| 1 | gongwen-guobiao（党政公文格式国标） | top-level(gongwen 套件) |
| 2 | gongwen-wenxi（六层算法：字词→句→段→结构→高观点） | top-level(gongwen 套件) |
| 3 | gongwen-draft（起草/修订/润色/审查/导出） | top-level(gongwen 套件) |
| 4 | gongwen-renmin（润色人性化，去 AI 腔） | top-level(gongwen 套件) |
- 为什么单技能不够：guobiao 管格式不管文采；wenxi 管算法但未必对齐国标；renmin 是最后人味关。只用一个 = 格式对但像模板，或文采好但格式错。
- 1+1>2：guobiao 锁边界 → wenxi 组织内容 → draft 起草 → renmin 去机械感，产出「合规 + 专业 + 像人」三层都过的公文。（同族技能串联，顺序即流水线。）
C3. AI 出图（文生图 → 验收 → 迭代）
| 步骤 | 技能 | category |
|---|---|---|
| 1 | prompt-engineering（提示词工程总入口，先路由分发） | palace-prompts |
| 2 | prompt-to-image-generation（提示词→Agnes API 出图实战链路） | creative |
| 3 | ai-media-generation（Agnes API 生图/生视频多风格预设） | creative |
| 4 | nuyoah-image-reverse-prompt（拿参考图反向拆提示词 / 验收一致性） | top-level |
- 为什么单技能不够：有提示词没 API 链路 = 出不了图；有 API 没提示词工程 = 图不对；出完不反向验收 = 和参考图偏差看不出。
- 1+1>2：prompt-engineering 定风格策略 → prompt-to-image-generation 跑通出图 → 不满意时用 nuyoah-image-reverse-prompt 反推参考图提示词 → 回到 prompt 层迭代，形成「文字→图→文字→图」闭环。
C4. AI 写真工作流（人像参考图 → 多场景写真）
| 步骤 | 技能 | category |
|---|---|---|
| 1 | nuyoah-xiezhen-prompt（写真/editorial 中文提示词生成改写） | top-level(symlink) |
| 2 | ai-portrait-workflow（参考图 → 多场景写真标准工作流） | creative |
| 3 | comfyui-portrait-optimization（ComfyUI 真人肖像生成优化技巧） | creative |
| 4 | comfyui-rtx3050（本地 4GB 显存跑 SD 1.5 的坑/选型） | creative |
- 为什么单技能不够：写真成败在提示词(1)+管线(2)+本地出图参数(3/4)。只用提示词 → 云端图贵且风格飘；只调 ComfyUI → 不知道怎么写人像提示词。
- 1+1>2：nuyoah-xiezhen-prompt 产出专业人像提示词 → ai-portrait-workflow 定多场景管线 → 本地用 comfyui-rtx3050 参数出图 + comfyui-portrait-optimization 调脸，成本从云端 API 降到本地 GPU。
C5. PPT / 演示文稿（要一页页好看、可汇报）
| 步骤 | 技能 | category |
|---|---|---|
| 1 | design-system-discipline（三层 token 视觉纪律，避免风格漂移） | top-level |
| 2 | guizang-ppt-skill（横向翻页网页 PPT，WebGL 背景+讲稿备注） | top-level |
| 3 | frontend-slides（动画丰富 HTML 演示） | top-level |
| 4 | dashi-ppt（主题化 PPT 生成，可离线打开） | top-level |
- 为什么单技能不够：dashi-ppt/guizang/frontend-slides 三个都是「生成器」但视觉基因不同；不先定 design-system 纪律，三个工具混用 = 每页一个风格。
- 1+1>2：design-system-discipline 定 token（颜色/字号/间距）→ 选 guizang（正式汇报）或 frontend-slides（炫技场）生成 → 快速出「一套视觉一致」的网页 PPT，而不是单工具默认模板拼盘。
C6. 短剧/漫剧/视频创作（剧本 → 分镜 → 素材 → 配音）
| 步骤 | 技能 | category |
|---|---|---|
| 1 | drama-script-writing（短剧/漫剧编剧方法论） | content |
| 2 | ai-video-storyboard-prompts（分镜/运镜提示词工程） | creative |
| 3 | ai-media-generation（Agnes 出图/出视频） | creative |
| 4 | tts-stt-tools 或 mimo-tts-pipeline（配音 TTS + opus 转码） | media |
- 为什么单技能不够：编剧给故事不给镜头；分镜给画面描述不给素材；素材生成了没人配音 = 片子不完整。四个环节环环依赖。
- 1+1>2：剧本 → 每场戏转分镜提示词 → Agnes 批量出素材 → TTS 配音合成，形成一条「文字→镜头→像素→声音」的短视频流水线（media category 补上最后一块）。
C7. 股票投研（选股 → 回测 → 每日信号）
| 步骤 | 技能 | category |
|---|---|---|
| 1 | stock-research（四维选股/回测对比/每日信号） | research |
| 2 | xlsx（把回测结果落成表格/对比） | productivity |
| 3 | provider-tiering（信号跑在免费模型上省钱） | devops |
- 为什么单技能不够：stock-research 给策略和信号；但结果要给人看要落 xlsx；且「每日信号」如果跑付费模型成本高。
- 1+1>2：stock-research 出信号 → xlsx 导出对比表 → cron 定时 + provider-tiering 选免费模型，形成低成本每日投研流水线（实际已有 stock_daily_signal_paper.sh 佐证该模式）。
C8. 自媒体运营（公众号/小红书 0→1 + 多平台分发）
| 步骤 | 技能 | category |
|---|---|---|
| 1 | marketing-disciplines（营销/SEO/CRO 方法论 + 科研工具索引） | top-level |
| 2 | multi-industry-prompts（70+ 行业文案模板） | content |
| 3 | social-media-ops（公众号+小红书从 0 到 1、内容创作分发） | social-media |
| 4 | feishu（做好的内容/协作发飞书） | social-media |
- 为什么单技能不够：营销方法论 ≠ 会写文案；文案模板 ≠ 懂平台调性；写完全靠手工发 = 不可持续。
- 1+1>2：marketing-disciplines 定选题/转化框架 → multi-industry-prompts 出对应行业文案 → social-media-ops 按平台规则排版分发 → feishu 推送预览，把「写一篇」变成「平台运营流水线」。
C9. 会议/访谈 → 行动项（要纪要+负责人+截止）
| 步骤 | 技能 | category |
|---|---|---|
| 1 | teams-meeting-pipeline（Teams 会议记录管线） | productivity |
| 2 | summarize-meeting（结构化纪要） | top-level |
| 3 | meeting-action-items（决策/负责人/DDL 提取） | productivity |
| 4 | weekly-review-planning（落进每周承诺/下周计划） | productivity |
- 为什么单技能不够：光纪要没行动项 = 听完就忘；光提行动项不进周计划 = 无人跟进。链路缺一不可。
- 1+1>2：会议转写 → summarize-meeting 成结构化纪要 → meeting-action-items 抽出「谁在何时前做什么」→ 汇入 weekly-review-planning，会议从「记录」变「可执行承诺」。（document-to-action-items 可补合同/文档类提取。）
C10. 网页抓取/反封锁（正文抓不到 / 403 / 墙）
| 步骤 | 技能 | category |
|---|---|---|
| 1 | blocked-page-recovery（403/429/paywall/WAF 回退；research 版为 canonical，web 副本已归档） | research |
| 2 | scrapling（stealth 浏览 + Cloudflare 绕过） | research |
| 3 | web-content-extraction（crawl4ai/scrapy/camofox/pymupdf 统一工具链） | productivity |
| 4 | firecrawl（网页→Markdown 一键） | productivity |
- 为什么单技能不够：firecrawl 能抓普通页但遇墙就挂；blocked-page-recovery 给策略不给你工具命令；scrapling 专破 Cloudflare 但输出糙。
- 1+1>2：firecrawl 先试 → 403 时 blocked-page-recovery 选回退路线 → scrapling stealth 硬抓 → 全文交给 web-content-extraction 统一清洗/转 md，形成「普通→硬核→清洗」三级抓取管线。
C11. 记忆系统维护（织忆/注入记忆 出问题或要治理）
| 步骤 | 技能 | category |
|---|---|---|
| 1 | memory-routing-contract（拿不准用哪套记忆/矛盾/自纠时） | knowledge |
| 2 | zhiyi（织忆 API/健康/运维规范，4 组件健康检查） | zhiyi |
| 3 | memory-verification（写入前检测矛盾/猜测/脱敏误判） | zhiyi |
| 4 | memory-governance（注入预算 + 淘汰 + 存储分层） | knowledge |
- 为什么单技能不够：zhiyi 管织忆服务本身，不管「该不该写这条记忆」；memory-governance 管预算但不懂织忆 API；没有 memory-verification = 脏记忆一直写进去。
- 1+1>2：memory-routing-contract 先裁决走哪套记忆 → zhiyi 拉真实健康 → 写入前 memory-verification 校验 → memory-governance 控制总量，形成「路由→健康→防污染→预算」记忆治理闭环。
C12. 技能库治理（curator 周报 / 技能太多要理）
| 步骤 | 技能 | category |
|---|---|---|
| 1 | skill-curator-workflow（curator 报告→人工判定→清理建议） | top-level |
| 2 | hermes-self-improvement（技能生命周期/质量标尺/删除规范） | autonomous-ai-agents |
| 3 | skill-library-porting（外部技能库批量移植） | knowledge |
| 4 | project-toolbox（判断当前任务用哪个已落地项目） | knowledge |
- 为什么单技能不够：curator 只出机械分档会误判（多次教训）；self-improvement 管质量但不产报告；porting 只管导入。
- 1+1>2：skill-curator-workflow 出本地真相报告 → hermes-self-improvement 的质量标尺 + 「删前验证」铁律兜底 → 需要恢复/移植时 skill-library-porting 走正规路径，技能治理从「瞎删」到「有门禁」。
C13. 代码质量门禁（提交前 / PR 审查 / 守护进程）
| 步骤 | 技能 | category |
|---|---|---|
| 1 | karpathy-code-discipline（写/审代码的诚实纪律） | top-level |
| 2 | requesting-code-review（提交前安全扫描/质量门/自动修） | software-development |
| 3 | github-code-review（PR 审查：diff/inline/gh/REST） | github |
| 4 | daemon-code-quality（daemon.py/soulful_core/hermes 插件专项审查） | autonomous-ai-agents |
- 为什么单技能不够：requesting-code-review 是通用门；github-code-review 管 PR 流程；但小唯守护进程有专属坑（systemd/pid 存活/时区）——通用审查发现不了。
- 1+1>2：karpathy 纪律打底 → requesting-code-review 本地自检 → github-code-review 走 PR 流程 → daemon-code-quality 专项扫守护进程，代码在「通用+专项」双保险下才放行。
C14. 数据库/存储损坏恢复（sqlite/lancedb/state.db 报错）
| 步骤 | 技能 | category |
|---|---|---|
| 1 | sqlite-db-corruption-recovery（SQLite 11 种损坏模式修复） | devops |
| 2 | lancedb-corruption-recovery（LanceDB 0 字节/向量丢失） | devops |
| 3 | cron-watchdog-hygiene（事故后审计 cron/watchdog，去重去自愈杀伤） | devops |
| 4 | self-healing-infrastructure（监控/回滚/自进化大框架） | devops |
- 为什么单技能不够：sqlite 修法 ≠ lancedb 修法 ≠ 事后 cron 审计；只修库不审 cron = 下次自愈脚本又杀库。
- 1+1>2：先按损坏类型进对应恢复技能 → 修完用 cron-watchdog-hygiene 排查「是不是 watchdog 误杀」→ self-healing-infrastructure 把防再发写进监控，单次救火变成系统免疫。
C15. 本地 LLM / GPU 推理部署（llama.cpp / 显存规划）
| 步骤 | 技能 | category |
|---|---|---|
| 1 | local-ai-infrastructure（需求/架构/硬件/模型选型） | mlops |
| 2 | local-llm-capacity-planning（小内存机选常驻模型：host-RSS/reasoning 坑） | mlops |
| 3 | llama-cpp（GGUF 本地推理 + HF 模型发现） | mlops |
| 4 | local-gpu-inference（Vulkan/ONNX CUDA 调优） | mlops |
- 为什么单技能不够：选型不容量规划 = 4GB 显存跑 7B 直接爆；容量对了不会 llama.cpp 命令 = 跑不起来；跑起来不会 GPU 调优 = 9t/s 难受。
- 1+1>2：local-ai-infrastructure 定架构 → local-llm-capacity-planning 按 16GB/4GB 硬件选 Q4 模型 → llama-cpp 部署 → local-gpu-inference 切 Vulkan/调参，复现「bge 走 CPU、llama 全 GPU → 14-43 t/s」的笔记本最优解。
C16. Docker/服务部署 + 内网穿透（容器化上公网）
| 步骤 | 技能 | category |
|---|---|---|
| 1 | docker / docker-management（构建/运行/编排） | devops |
| 2 | nginx（反代/SSL/负载均衡） | devops |
| 3 | self-hosted-tunneling（FRP：frps 云 + frpc 家服，公网暴露） | devops |
| 4 | windows-home-server-ops（家服 Windows/ZSB GPU 部署运维） | devops |
- 为什么单技能不够：docker 管容器不管入口；nginx 管入口不暴露公网；tunneling 只给隧道；家服那台 Windows 有自己坑（frpc.exe 闪退、DirectML）。
- 1+1>2：docker 起服务 → nginx 反代/SSL → self-hosted-tunneling 走 frpc（iStoreOS 24h 跑，避开 Win frpc.exe 坑）→ windows-home-server-ops 按家服真实拓扑运维，形成「容器→入口→公网→硬件」完整上线路。
C17. 语音管线（STT 转写 + TTS 合成 + 转码发送）
| 步骤 | 技能 | category |
|---|---|---|
| 1 | whisper-stt（本地 faster-whisper 离线转写） | top-level |
| 2 | tts-stt-tools（edge-tts + GLM-ASR 免本地模型方案） | media |
| 3 | mimo-tts-pipeline（MiMo TTS wav→opus + ffmpeg 参数） | media |
| 4 | feishu（发语音消息到飞书） | social-media |
- 为什么单技能不够：whisper 要下模型本地跑；tts-stt-tools 走云端 API 但转码不在行；mimo 强在音质但没平台发送。
- 1+1>2：按资源选 whisper（离线）或 tts-stt-tools（云端）→ 合成后 mimo-tts-pipeline 转 opus（飞书不吃 wav）→ feishu 发语音，形成「转写/合成→转码→发送」闭环。
C18. 任务委派/多智能体编排（大目标 → 拆 → 并行 → 验收）
| 步骤 | 技能 | category |
|---|---|---|
| 1 | kanban-routing / kanban-router（先判断路由：research/dsh/npc/opencode/delegate） | top-level |
| 2 | team-composer（按任务类型组队：144 skill + 184 ao 角色） | autonomous-ai-agents |
| 3 | ao-orchestrator（ao compose 多角色 DAG 执行） | autonomous-ai-agents |
| 4 | subagent-driven-development（delegate_task 子代理两段式审查执行） | software-development |
- 为什么单技能不够：kanban-routing 只告诉你「派给谁」，不给怎么组队；team-composer 给组队不给执行引擎；ao 给引擎但复杂任务要显式 YAML；subagent 给子代理但需要父进程验收。
- 1+1>2：kanban-routing 定路由 → team-composer 定角色组合 → ao compose 生成 DAG 并行 → 关键代码走 subagent-driven-development 两段式审查，把「模糊大目标」变「多角色并行流水线 + 验收」。（全链路实际已被 kanban 分身/ao 阵法验证。）
附 A：验证命令（每个技能名都在磁盘存在）
cd ~/.hermes/skills && for n in <技能名>; do find . -maxdepth 4 -type d -name "$n" -not -path '*/node_modules/*' | head -1; done
# nuyoah-xiezhen-prompt 是符号链接 → ls -la ~/.hermes/skills/nuyoah-xiezhen-prompt
附 B：组合使用提示
- 同一任务多个画像命中 → 链式叠加（如 C9 → C13：会议提出代码任务 → 代码质量门禁）。
- 每链第 1 个通常是「入口/策略」技能（prompt-engineering / skill-curator-workflow / memory-routing-contract 类），起路由作用。
- 通用技能层优先于专业链内嵌：专业链只管领域执行，通用层（规划/验收/复盘）按 §1.2 在外面套，不要写进每一条（避免重复）。
- 组合里技能顺序 = 数据流方向；顺序错了效果打折（例如先抓取后定引用纪律 = 白抓）。