一键搭建 Harness 框架

问题背景

很多团队把 Agent 能力全押在模型选型上，却忽略运行环境：跨会话失忆、上下文被无关文件撑爆、改完代码没人跑验证，协作越久越像「每次从零开始」。Harness Engineering 的核心观点是 Agent = Model + Harness——模型定下限，轨道系统定上限。

技能如何工作

本技能以 Harness Architect 角色按阶段初始化工作区，不写业务代码，只搭基建：

• Phase 0 环境扫描：识别 Unity / Node / Python / Go 等项目类型，检测 Git 或 SVN，盘点 .workbuddy/、.codebuddy/、CODEBUDDY.md 等已有资产，输出扫描报告并等待确认。
• Phase 1 记忆系统：创建 .workbuddy/memory/ 骨架，生成或增量补齐 MEMORY.md（ADR、Gotchas、偏好、进行中议题等），不覆盖已有内容。
• Phase 2 上下文工程：在项目根生成精简的 CODEBUDDY.md（约 200 行内），作为项目级知识契约；大型 monorepo 可按模块追加局部上下文。
• Phase 3 Rules：在 .codebuddy/rules/ 写入 harness-core.md 与按需的 harness-verify.md，并按版本控制类型注入 git diff 或 svn status 等验证约束。
• Phase 4～5：七项 Harness 体检（记忆分层、上下文入口等）给出青铜～钻石段位，汇总文件清单、使用指南，并写入当天 daily log。

设计强调概率性生成 + 确定性校验、分层记忆（L0～L3）与「存储一切有价值且可被找到」。

适用边界

• 只增不改：已有 CODEBUDDY.md 等文件不会被整文件覆盖，仅补缺失章节。
• 渐进式：先搭骨架，细节靠后续迭代；MEMORY.md 建议控制在约 300 行内。
• 无版本控制时会在体检中标注缺失项，验证 Rule 会相应简化。
• 实战取向来自游戏/配置表等复杂工程（含 SVN、大量 Excel/CSV），通用文档仓同样可用，但子目录上下文主要面向模块清晰的大项目。