编码规范与文档规范本身算不算repoharness，Claudecode本身就有内置的一些协作的规范。

回复 群友 2434： 算，但要看它是“通用的写代码习惯”还是“你们仓库独有的历史与约定”；同时还要区分 Claude Code 自带的“产品级能力”和真正装在代码库里的“Repo 级内容”。 按 Joye 在《Agent Harness 的三层》里的主线：通用的补丁早晚会被下一代模型吸收，但 Harness 不会变小，而是在往外长——从单个产品，长到 Repo，再长到整个组织。用这个视角切开看就很清楚了： 1. 为什么说你写的编码规范与文档规范算 Repo Harness，但有高下之分 如果规范里写的是“变量命名用驼峰、函数别超过 50 行、写完代码记得跑测试”，这其实是通用编码常识。模型稍微升级换代，或者 ca（codingAgent）内置的默认提示词一覆盖，这些东西就变成冗余废话了。 真正构成核心 Repo Harness 的，是任何外部大模型怎么训练都不可能知道的“仓库独有上下文”： 比如架构与目录地图（哪个模块负责鉴权、为什么要拆成两个包）； 比如历史包袱与暗坑（某段代码写得很绕是为了兼容三年前的线上旧数据，千万别看着像冗余就随手重构删掉）； 再比如这个项目特有的验证链路（改完数据库 schema 后必须跑哪条特定脚本重新生成类型、用什么命令起本地测试容器）。把这些沉淀成 AGENTS.md、CLAUDE.md，并配好代码修改后自动触发 lint 和跑单测的确定性 Hook，才算是把 Repo Harness 立住了。 2. Claude Code 内置的协作规范（产品级 Harness） vs 你们自己的 Repo Harness 你提到的“Claude Code 自带内置规范”，本质上是产品级 Harness 给的空壳和通用脚手架，它解决不了跨人、跨 Agent 改同一个仓库时的信息同步问题： 首先，Claude Code 内置的是“机制”（比如它知道进项目先自动读取根目录的 CLAUDE.md、知道怎么调 git 提 PR、怎么派发子任务），但它是个空盒子，里面装的还得是你们项目自己的业务规矩。 其次，Repo Harness 最核心的痛点是“多 Agent 协作与防冲突”。当团队里五个人每人开一个 Claude Code 同时改一个仓库时，单个 ca 再守规矩也没用：A 的 ca 改了底层接口的参数约定，B 的 ca 在另一个分支上完全不知道，还在按旧约定调接口；或者两个 issue 改了同一块核心逻辑但前提互相矛盾。 所以结论很简单： Claude Code 内置的规范只是让单个 ca“懂礼貌、会用工具”（属于产品级 Harness，甚至慢慢会被模型内化）；而你们仓库里的文档规范、架构地图、自动检查 Hook，以及多 Agent 并行修改时的任务拆解、接口变更同步、合并前交叉验收机制，才是真正属于你们自己、且永远不会被大模型吞掉的 Repo Harness。