提示词是建议，Harness让规则落地：AI Coding 从个人实践到团队标准

▍知识能力：让 AI 拥有持续积累的工程记忆

统一流程解决的是“AI 应该怎么工作”，但仍然没有解决另一个问题：AI 每次都会重新开始。

团队首先为两个核心项目建设结构化模块知识库，初始分别覆盖 22 个和 18 个模块。随着第三个项目和跨项目知识补充，当前仓库已沉淀 110 份知识类 Markdown，内容覆盖模块职责、接口约束、核心数据流、调试方法和历史设计决策。

知识库并不是一次生成后永久可信。首次深度审计中，一个项目发现并修复了 15 项高风险、37 项中风险和 30 项低风险知识错误，并补充 64 项遗漏。这推动团队建立知识刷新和验证管道，让 AI 读取的不只是“有文档”，而是经过持续校验的工程上下文。

在后续需求中，AI 已经能够在 brainstorm 阶段主动读取模块手册，并据此分析多个字段在不同实现类中的分布。不过，知识库对代码正确率和线上缺陷的量化影响仍缺少严格对照数据，团队暂不将其换算为提升百分比。

▍团队资产：从一个项目到所有项目

早期约束逻辑散落在每个项目目录中，靠 rsync 或 git pull 分发，版本不统一，门禁行为也不一致。团队通过插件化分发解决这一问题：将约束逻辑、门禁脚本和命令定义打包成独立的 Claude Code 插件，通过内部 Marketplace 统一发布。维护者更新项目引用的目标版本后，启用自动更新的客户端会在启动时检查并拉取新版本，开发者重启会话或重新加载插件后即可生效。插件架构包含三个关键设计：

• SessionStart 自举：每次会话启动时，插件自动执行幂等注入——检查目标项目的 hooks 配置是否需要更新，清理孤儿 hooks，确保门禁脚本版本匹配。开发者无需手动配置。

  
  

• 双策略同步：默认模式下插件每次覆盖目标项目中的门禁脚本和命令定义，保证一致性；也支持项目锁定特定版本，仅初始化缺失文件，不覆盖已有配置。

  
  

• 状态文件防篡改：.workflow-state.json 是受门禁保护的流程记录。PreToolUse 拦截 Edit/Write 对该文件的直接修改，Bash 状态守卫同时检查可能篡改状态的命令；流程更新的唯一受支持入口，是通过门禁验证后的 mark-step 子命令。在纳入管控的 Claude Code 工具路径内，AI 无法直接绕过流程状态。

  
  

代价是维护复杂度集中化，要求插件发版前有严格的回归验证。这标志着 AI 辅助开发，从一种依赖个人经验和纪律的“手工作坊”，正式演变为可分发、可升级、可审计的工程基础设施。

从 2026 年 4 月 24 日至 6 月 5 日，工作流覆盖了 3 个业务项目和 6 名开发者，完成 23 个正式需求的流程归档；同期仓库中另有 123 个带 AI 标记的提交，但 AI 标记提交不等同于完整 Flow，因此不计入流程合规样本。最大的变化不是 AI 写得更快，而是团队第一次拥有了统一的开发过程——不同项目使用同一套 Flow、同一套知识库和同一套门禁规则。AI 的行为不再依赖个人提示词，而变成了团队共享的工程能力。

团队最初最不适应的不是工具操作，而是“编码前必须把需求问清楚”。AI 会持续追问边界、异常路径、兼容策略和验收方式。对于习惯先写代码、遇到问题再调整的开发者来说，这种刨根问底的过程一开始很难接受。

使用一段时间后，大家认可的收益也不只是代码生成更快，而是开发设计有文档、各阶段耗时有记录、需求到实现的过程能够回看，并且流程不会因为赶进度而被轻易跳过。当前最集中的改进诉求是：为标准 Flow 提供低风险小需求的轻量路径，以及开发中途发现问题后的局部返工路径。

04

最初团队想解决的是“AI 为什么总是不按流程来”，但后来发现，问题并不是 AI 不听话，而是传统软件工程默认存在的人类约束，在 AI 参与后失效了。工具解决的是一个人能不能用好 AI，而团队需要的是所有人都能稳定地用好 AI。前者靠个人经验，后者靠系统设计。

目前，这套体系已在 3 个项目中完成验证（数据见第三章）。除了流程和知识的沉淀，这套体系带来的更大变化，是开发方式本身发生了改变。

一是前置审查。在人工 Review 之前，产出先由 implementer 完成，再经过 spec-review 和 quality-review 两层自动审查。过去典型需求通常需要约两轮人工 Review；引入 Harness 后，并不是简单减少评审动作，而是把规格一致性、实现完整性和基础质量检查前置，让人工 Review 更聚焦于业务判断与架构取舍。开发者打开需求时，也能清楚看到哪些决策已经确认、哪些问题仍待解决，不再从零开始读代码。二是经验效率。根据同类需求常规排期与实际 Flow 耗时的经验对比，部分需求可节省约 40%—50% 的开发时间。这个数字是团队经验口径，不是严格对照实验；更准确地说，流程标准化让产出过程更可预期。

距离 AI 真正成为团队成员，还有几个关键差距需要弥合：

1. 平台锁定风险：深度依赖 Claude Code 的 Hook API，适配其他平台需重写门禁引擎。抽象层应面向“能力接口”而非特定产品。

2. Bus Factor = 1：整个约束引擎是一人维护的 2600 行 Bash，团队其他人看不懂也不敢改——这本身就违背了“工程化”的初衷。

3. 适用范围仍需扩展验证：这套方法不局限于 Monorepo，核心的阶段守卫、证据校验和质量门禁同样适用于单仓库或多仓库项目。当前样本主要来自 Monorepo，迁移到多仓库架构时仍需补充跨仓库状态协调、版本一致性和权限边界验证。

4. 标准流程偏重：对于低风险小改动，完整的需求分析、方案、TDD 和评审链路成本较高；开发中途发现问题时，也缺少足够自然的局部返工路径。团队下一阶段将重点探索轻量小需求 Flow 和问题返工 Flow。

   
   

此外，因果链尚未完全建立（合规率到业务结果的归因仍在积累样本）、双通道在 AI 自验证场景下会退化为单通道、知识注入在业务逻辑隐含约束上仍有天花板——这些开放问题正在迭代中。

05

这套方案是内部插件，未开源。但如果你看完想在自己团队试一试，下面是一个不依赖任何内部基础设施的最小起步路径（仅要求使用 Claude Code）：

1. 第一步：一个状态文件 + 一个阶段守卫。 在项目根目录放 .workflow-state.json，内容只有 {"stage": "brainstorm"}。然后写一个 PreToolUse Hook，在 stage != "implement" 时拦截对 src/ 的 Edit/Write。它可以先约束 Claude Code 内置工具的直接源码修改；若希望形成“方案未定稿前不能写代码”的完整强约束，还需同时检查可能写入源码的 Bash 命令、MCP 工具及其他文件写入路径。

   
   

2. 第二步：给关键步骤加产物落盘。 用 PostToolUse Hook 在 AI 写完这些文件后自动往状态文件追加一条事件记录（注：最小版本未启用防篡改守卫，故可直接写；生产环境应改为通过专用 mark-step 子命令写入）。

   
   

3. 第三步：按需融合 OpenSpec / Superpowers。 当 OpenSpec 的规格化工件、Superpowers 的技能编排和 Hook 门禁三者接在一起时，才进入本文所说的 Harness 完整形态；但它不是起点。

   
   

不要一开始就做的事：不要一上来就写约 2600 行的 Bash 门禁引擎。先用 50 行左右的脚本跑通“一个状态文件 + 一个拦截器”，用一周观察 AI 的真实行为，再决定是否增加约束。约束是被实际问题推出来的，而不是一次规划完成的——这是这套系统多轮演进中最重要的教训。

一句话判断：如果痛点是“AI 写的代码不可审计、不可追溯”，这套方案能够直接改善；如果痛点是“AI 写的代码质量不够好”，它能提高问题被测试、门禁和评审提前发现的概率，但不能提升模型本身的能力上限。

软件工程的每一次重大跃迁，解决的都是同一个问题：如何把个人能力变成团队能力。版本控制解决了代码协作，CI/CD 解决了交付协作，Code Review 解决了质量协作。现在，AI 正在成为团队中新的执行者——但 AI 的能力不会自动变成团队能力。它需要流程、知识、质量和审计，才能真正参与软件工程。

今天，当一个新需求进入系统，AI 会先完成 brainstorm，列出待澄清问题，等待方案评审通过后才能开始写代码。整个过程留下的不是一段聊天记录，而是一条完整的工程审计链。无需依赖开发者反复提醒；在门禁覆盖的工具路径内，未满足前置条件的操作无法直接通过。

当 AI 开始参与软件工程时，真正需要被系统化的，不只是代码生成能力，而是团队的软件工程方法。提示词决定 AI 会说什么，Harness 决定 AI 能做什么。