← 返回作品集行途 · 作品集

行途工作空间 · Harness 体系手册

把「自媒体复利工程」也当作一套 Harness 来经营 —— 内容创作、调研、开发、开源,全部在受控轨道上运行。

版本 V1.02026-08-19基于 某零售供应链/Ctf / TFM-NG / Haiting 三套 CC Harness 蒸馏面向 WorkBuddy 兼容

一、Harness 是什么 理论

你在 重构工程仓 的 HARNESS.md 里已经定调:「将 Harness 视为产品,而非配置文件集合」「某零售供应链 Harness = AI 编码的操作系统」。

把这句话从「编码」泛化到「工作空间」就是本手册的核心命题:

Harness = 把一个人的工程纪律、方法论、工具链、记忆,沉淀成 AI 可读、可强制执行、可跨项目复用的资产库。
AI 是「选手」,在受控轨道上运行;人是「裁判」,负责审查与决策;同一套标准,人与 AI 共用。

为什么内容工作空间也需要 Harness

一句话:Harness 不是把工作交给 AI,而是把「你如何把工作做对」交给 AI。

二、六层架构模型 框架

直接复用你 重构工程仓 的 L0–L5 分层(已在 Haiting 的 HARNESS.md 验证可移植),并补上「路标层 / 锚点」两个横向角色。xingtu 的现有目录会被映射到这些层(见第四节)。

L5 产品层
HARNESS.md / 工作看板
愿景、路线图、进化机制、防腐规则。本手册即 xingtu 的 L5。
L4 编排层
workflows/
任务类型的流水线 SOP:内容生命周期、调研、开发、开源。
L3 执行层
skills/ + agents/
可复用的能力包(排版引擎、选题挖掘、对标拆解)与专家角色(调研/开发/审查)。
L2 护栏层
rules/ + specs/
宪法级约束(SEO 红线、分发差异化、安全)与 Spec 驱动开发模板。
L1 土壤层
config + scripts/
环境配置(models.json / mcp.json)+ 工具脚本(排版、索引、benchmark)。
L0 记忆层
memory/ + incidents/
跨会话记忆、踩坑 BCI 库、复盘日志(你已有 .workbuddy/memory + 04_会话与复盘)。
三个横向角色(不属于某一层,贯穿所有层):
  • 路标层README.md + DIRECTORY.md + 工作看板 —— 让 AI/新人 30 分钟上手,知道「资产在哪、该读哪个」。
  • 锚点CLAUDE.md(CC)/ SOUL.md(WB)+ config.yaml —— 行为定位 + 单一事实源(SSoT)。
  • 渐进式披露:L1 只放索引(~50 token),命中才加载 L2 正文(<5000 token),引用才进 L3 资源。Token 经济是第一公民。

三、八大核心机制 原则

这些是「某零售供应链 / Haiting」验证过的、可迁移到内容空间的机制。每条都标注了 xingtu 现成载体。

机制含义xingtu 落地载体(已存在 / 待建)
① 渐进式披露分层按需加载,省 Token;Caveman 压缩输出(直接结论+证据,不客套)。已有:DIRECTORY.md(待建索引)、SOUL.md 注入。待建:L1 索引 / L2 规则正文分离。
② SSoT 单一事实源一个真相源,别处引用。避免多处矛盾。已有:config 用 models.json/mcp.json;IP 战略以 .workbuddy/memory/MEMORY.md 为准。待建:资产注册中心 DIRECTORY.md。
③ 强编号 / 强注册规则/资产带编号 + 注册表,引用可 deep-link,审查可溯源。待建:把 01_战略与规章、rules 编号化(如 SEO-001、FEN-001);DIRECTORY.md 做唯一注册。
④ Spec 驱动 + Hard Gate「无 Spec 不写码」;门禁把承诺变运行时强制(写前必跑)。开发/开源任务复用:CC 的 gate.sh 思路 → xingtu 的「发布前清单」。内容任务轻量版 Spec(选题卡→成稿→排版→分发)。
⑤ 对抗性审查多视角围攻同一产物,不 dedup、不降级;脚本交叉验证替代 LLM 当法官。内容复用:成稿后「三角色审查」(事实核对 / 利他性 / 平台适配);可用 WB 子 Agent 并行。
⑥ 写审分离 + 主会话协调写 agent 只产出,审 agent 只挑刺,主会话仲裁收口。WB 天然支持:Agent 子代理写、主会话聚合;CC 同样用 Subagent 蜂群。
⑦ 知识回流 + BCI踩坑沉淀反模式库,审查自动匹配;跨项目验证的通用资产回流共享池。已有强载体ai_collab_miner.pyai_history_indexer.py04_会话与复盘、BCI 概念待建文件。
⑧ 防腐 + 自包含活文档行数上限;超则拆分/归档;组件准入五问;产物可整体移植。待建:对 02_内容仓库/03_运营工具箱 设保鲜期;对 tools/ 设「必要性五问」准入。
跨平台兼容原则(来自 Haiting §十一):共享层(rules/config/specs/scripts)两平台同读;平台专属能力(CC 的 hooks/skills/agents,WB 的 Skills/Expert/自动化)各放各处,靠维护规则保证一致。这是第六节的基础。

四、xingtu 工作空间 harness 化映射 落地

不重命名你精心设计的 01_~05_ 目录,而是「叠加 harness 视角」重新诠释它们属于哪一层,并补上缺失的锚点/路标文件。

现有载体(xingtu)harness 角色说明
L5 产品README.md00_自媒体复利工作看板_Canvas.md已是路标+看板。补一个 HARNESS.md(本手册的轻量锚点版)即可。
L4 编排03_运营工具箱(排版规范/分发 SOP)已是 workflow 雏形。待建 workflows/:内容生命周期、调研、开发、开源 4 条 SOP。
L3 执行tools/(排版引擎、索引器、benchmark)、WorkBuddy Skills排版/选题/对标 = skills;专家角色 = WB Expert 或 CC agents。
L2 护栏01_战略与规章(IP 战略/排期)、SEO 与分发规则这是「内容宪法」。待编号化为 rules(SEO-001 等)。
L1 土壤~/.workbuddy/models.jsonmcp.jsontools/*.py/*.js模型/连接器配置 + 可跨平台运行的脚本。
L0 记忆.workbuddy/memory/(日log+MEMORY.md)、04_会话与复盘06_Obsidian已是记忆层主力。ai_*_indexer 提供跨会话检索。
路标README.md(已有)、DIRECTORY.md(待建)资产唯一注册中心,告诉 AI「要找 X 去哪」。强烈建议建。
锚点SOUL.md/USER.md/IDENTITY.md(WB 已注入)WB 侧身份锚点;CC 侧暂无项目级 CLAUDE.md(见第六节兼容)。
关键判断:你 xingtu 的「记忆层 + 工具层」已经比很多 CC 项目还完整(ai_collab_miner / ai_history_indexer 是 CC 想要却常缺的)。真正缺的是 L2 规则编号化、L4 工作流 SOP、以及 L5/Directory 两个锚点文件——这三件就是落地路线图的重点。

五、四类任务路由 执行

你点名要便于执行「指向性 / 调研 / 开发 / 开源」四类任务。下面给出每类的触发识别、走哪层、用什么能力、产出放哪。

① 指向性任务(Directed)

维度说明
识别信号明确窄指令:「把这篇转公众号排版」「跑一下 ai_collab_miner」「生成 benchmark 图」。
路由直接执行 + Task 系统拆步(>2 步必拆);静默执行、只报增量/异常(你 CC CLAUDE.md 的进度可见性铁律同样适用 WB)。
用到的层L1 脚本(tools/)、L3 skill(排版引擎/索引器)、L0 记忆。
产出落到对应目录:排版稿→02_内容仓库/03_待审与排版;索引结果→tools/ 输出或 outputs/

② 调研任务(Research)

维度说明
识别信号「调研 X 工具」「对比 Y 与 Z」「查 2026 最新方案」「竞品拆一下」。
路由并行 WebSearch(不串行)→ 渐进式披露只载入相关 rules → 输出结构化报告。造轮子前先搜成熟方案(你 CC 铁律)。
用到的层L2 护栏(调研规范)、L4 编排(research workflow)、L0 记忆(避免重复调研)。
产出报告→05_竞品参考与对标(隔离区,防污染内容库)或 02_内容仓库/01_灵感与选题池(若成选题)。

③ 开发任务(Dev)

维度说明
识别信号「写个脚本/工具」「搭个站点」「给 xingtu 加个功能」。涉及代码产出。
路由Spec 驱动:先出方案(Plan)→ 轻量 Spec(需求/设计/任务/验收)→ 写码 → Hard Gate(测试/自测绿了才合)→ 对抗审查。写审分离,主会话收口。
用到的层L2 specs、L3 agents/skills、L1 scripts(env-check/gate)、L0 memory(BCI 防踩坑)。
产出代码→tools/ 或新仓库;Spec→specs/(待建);复盘→04_会话与复盘

④ 开源任务(Open Source)

维度说明
识别信号「整理成 GitHub 仓库发布」「把 X 工具开源」「出英文版出海」。
路由自包含检查(无外部本地路径依赖)→ 文档化(README+Spec 摘要+License)→ 多平台分发(国内 GitHub / 海外 Dev.to+LinkedIn)。知识回流标注来源。
用到的层L5 产品(发布清单)、L2 specs、L1 scripts(打包/自包含校验)、出海规则(见 MEMORY.md §5)。
产出仓库(GitHub publish 工作空间);英文改写→海外阵地;结汇/收款走 PayPal+PingPong(MEMORY.md §5)。
冲突消解规则(沿用 CC):多匹配时优先级 开发/开源 > 调研 > 指向性;消息无动作词→不路由,直接对话。避免「一句话触发重流程」。

六、Claude Code ↔ WorkBuddy 兼容映射 关键

你主阵地是 Claude Code CLI 搭的 harness,现在要跟 WorkBuddy 并存。好消息:你的 harness 资产大部分能双向复用。下表逐项给出映射与复用策略。

CC Harness 概念WorkBuddy 对应物复用策略兼容度
CLAUDE.md
(角色/铁律/路由)
SOUL.md+USER.md+IDENTITY.md(已注入);项目级靠 Skill / memory角色/语言/铁律写进 SOUL.md(已做)。项目专属规则用 WB Skill 或 memory/MEMORY.md 承载,不要指望 WB 自动读 CLAUDE.md。高(部分)
settings.json / settings.local.json
(权限白名单)
WB 工具审批机制(运行时用户批准);连接器/自动化状态管理无等价静态 allow/deny 文件。把「rm 永不授权」等偏好固化进 SOUL.md + 用 safe-delete.sh 行为约束,而非权限文件。中(范式不同)
hooks/
(session-start/end, 提醒)
WB 无 hook 框架替代:① automation_update 定时任务模拟 SessionStart 类动作;② agent_loop 内建「每日记忆追加」靠 Skill 约定;③ 提醒类用自动化。CC 的 cbm/ponytail 提醒可转成 WB 自动化。中(需重构)
scheduled_tasks.json
(cron 定时)
automation_update
(rrule / once / scheduledAt)
直接等价。你 CC 里的 HARNESS-WATCH 周检、dsh 更新检查,可 1:1 迁到 WB 自动化(rrule 周/日)。高(等价)
agents/
(Subagent 定义)
Agent 子代理 + Expert 系统(expert-manager)CC agent 定义(如 architecture-expert)→ 转成 WB Expert 专家包,或作为 Agent 子代理 prompt 复用。写审分离模式通用。
skills/
(SKILL.md SOP)
WB Skills(Skill 工具 + ~/.workbuddy/skills最大红利:CC 的 SKILL.md 格式与 WB Skill 几乎一致,可直接迁移/共享。你的 adversarial-review / ponytail / tdd 等 skill 两边都能用。高(红利)
commands/
(slash 命令)
WB 斜杠命令 / 用 Skill 承载CC /code-review 等 → 注册为 WB Skill 即可调用。WB 没有独立 commands 目录,统一用 Skill。
specs/
(SDD 6 文件)
WB 无原生 spec,可用 Skill/Markdown 实现开发/开源任务走 Spec:在 xingtu 建 specs/ 目录复用 CC 的 _TEMPLATE。WB 侧用 Skill 引导 Spec 流程。
scripts/
(bash/sh/js)
WB Bash 工具直接运行完全共享:safe-delete.sh、env-check.sh、gate.sh、kb-server.js,以及 xingtu 的排版/索引脚本,两边同跑。这是最稳的跨平台纽带。高(共享)
memory/
(MEMORY.md, BCI)
WB memory 体系(user MEMORY.md + workspace memory + conversation_searchBCI 反模式库→转 WB memory 或 Skill;跨会话检索用 conversation_search。你 xingtu 的 ai_history_indexer 已是超集。
mcpServersWB Connectors~/.workbuddy/mcp.json)+ 已连接连接器MCP 配置两平台共用 mcp.json 思路;WB 把外部能力包装为 Connector,CC 用 mcpServers。同一份网关/Key 可双挂。
config.yaml
(SSoT)
models.json / mcp.json + memory 承载保留 config.yaml 作为跨平台 SSoT(技术栈/端口/脚本路径),WB 侧用 memory 引用它,不要双写。
三条兼容铁律(建议写进 SOUL.md / CLAUDE.md):
  1. 共享层不分裂:rules / config / specs / scripts 是 CC 与 WB 的共同资产,放中性位置(如 tools/ 或独立 .harness/),两边同读。
  2. 平台专属各归各家:CC 的 hooks/agents 留 CC;WB 的 Skills/Expert/自动化留 WB。别把 CC hook 脚本硬塞进 WB。
  3. Skill 是最大公约数:凡是可复用的能力包,优先写成 Skill 格式(SKILL.md),CC 当 skill 用、WB 当 Skill 用,一份资产双平台生效。

七、工具与脚本复用清单 资产

盘点你两边的脚本资产,标注哪些可跨平台直接复用、哪些值得双向移植。

xingtu 原生工具(已在用,CC 侧可借)

脚本作用跨平台价值
ai_collab_miner.py扫描 .claude 会话+项目改动,挑可成内容的协作片段→ CC 侧的「知识回流」引擎;在 CC 项目里也能跑,反哺内容选题。
ai_history_indexer.py + ai_history_report.py统一索引多 harness 历史会话,生成可检索看板→ 替代 CC 的 sessions/journal.md 检索;WB 用 Bash 直接调。
project_indexer/索引 /projects 实践痕迹,按关键词抓素材→ 两平台共用的「素材供给」;给自媒体供料。
tokenhub_bench.py / tokenhub_minigate.py模型榜单评测 / 网关→ 模型评估 workflow;CC 与 WB 都可用,统一评测口径。
wechat-format/ 排版引擎、render_wechat.js公众号排版→ 内容生产 skill 的核心;CLI 调,GUI 编排。
wechat_chat_analyzer/聊天记录分析→ 社群/私域洞察;可接 WB 自动化定期跑。
cc-switch-*.pyCC 配置文件/模型切换→ CC 专属,但思路可给 WB 做模型切换参考。

CC Harness 脚本(值得迁到 xingtu)

脚本作用迁移到 xingtu 的用处
safe-delete.shmv 到回收站替代 rm,带 --restore必迁:你 SOUL/USER 已强调「删除前求确认」。xingtu 清理/归档用同一套安全删除。
env-check.sh环境一键自检(凭据/工具链/连通性)改编为 xingtu 版:检查 Python venv、node workspace、models.json、mcp.json 是否就绪。
gate.shHard Gate G1-G3 前置检查→ 内容「发布前清单」脚本:Spec 齐?自测过?合规过?不绿不准发。
kb-server.js + kb-viewer.html本地知识浏览器(Mermaid+搜索)→ 把 xingtu 的 06_Obsidian + 01_战略 变成可团队共享的网页看板。
spec-monitor.sh多 Spec 并行状态监控→ 开发/开源任务并行推进时的进度雷达。
cbm hooks(session-reminder 等)会话提醒/复盘→ 转 WB 自动化(每日/每周),模拟 SessionEnd 记 journal。
复用红线:脚本只放「中性位置」(tools/.harness/scripts/),用相对路径/参数传参,禁止硬编码绝对路径,否则破坏「自包含」、无法在纯净环境(AVD/另一台机/WB 沙箱)跑。

八、落地路线图 行动

分四阶段,按「先补锚点 → 再固化规则 → 跑通路由 → 双向打通」推进。标注安全度:可立即做 需你确认 建议做

Phase 0

补锚点与路标

  • 安全HARNESS.md(轻量版,本手册浓缩)
  • 安全DIRECTORY.md(资产注册中心)
  • 安全 把本节结论回填 SOUL.md 三条兼容铁律
Phase 1

L2 规则编号化

  • 建议 把 01_战略与规章 提炼为编号 rules:SEO-001、FEN-001(分发)、SAF-001(安全)
  • 建议rules/ 目录,CC 与 WB 同读
  • 确认 是否把现有 100+ 内容文件重命名为 kebab-case
Phase 2

L4 工作流 SOP

  • 建议 写 4 条 workflow:内容生命周期 / 调研 / 开发 / 开源
  • 建议 把排版引擎、选题挖掘、对标拆解封装成 WB Skills
  • 安全safe-delete.sh + 改编 env-check.sh
Phase 3

CC↔WB 双向打通

  • 建议 CC scheduled_tasks → WB 自动化(HARNESS-WATCH 周检等)
  • 确认 是否把 CC 的 adversarial-review/ponytail skill 迁为 WB Skill
  • 建议 用 kb-server 把知识库网页化共享
最小可行第一步(建议本次就落):只建 HARNESS.md + DIRECTORY.md 两个文件(已随本手册生成于 xingtu 根),其余 Phase 1–3 作为待办。这两个文件零风险、纯新增,立刻让任何 AI(CC 或 WB)进到 xingtu 时知道「这是什么空间、资产在哪、该守什么纪律」。

附录:术语与引用 参考

术语含义
Harness把工程纪律/方法论/工具链/记忆沉淀为 AI 可读、可强制执行、可复用的资产库(你定义为「AI 的操作系统」)。
SSoTSingle Source of Truth,单一事实源。一处定义,处处引用。
渐进式披露Progressive Disclosure,分层按需加载以省 Token。
SDD / SpecSpec-Driven Development,规范驱动开发;标准 Spec = 6 文件(README+analysis/requirements/design/validator/tasks)。
Hard Gate把「无 Spec 不写码 / 测试先于码 / 验收全绿」从 Markdown 承诺变成运行时强制(gate.sh)。
对抗性审查Adversarial Review,多角色围攻同一产物,不 dedup、不降级,命中次数=致命度。
BCIBad-Case Index,反模式/踩坑库,审查时自动匹配。
防腐Anti-bloat,活文档行数上限 + 组件准入五问 + 保鲜期归档。

引用来源(你已有的资产)

行途工作空间 · Harness 体系手册 V1.0 · 2026-08-19 · 由 WorkBuddy(小研)整理,蒸馏自某零售供应链/Ctf、TFM-NG、Haiting 三套 Claude Code Harness