AI写得快不等于真正提效：Harness 记忆与验证闭环
一句话概括
焦成杰用分层知识索引、工具调用钩子、引用治理和可等待的交付流程，把跨会话经验与实际验证接起来。原文
实践内容
以下为实现约束的转述；原始脚本和指令见原文对应小节。
- 知识入口：总索引
agents.md路由到模块索引agents2.md，再读具体文档。记录探索所得的误判陷阱、关键代码位置及隐含连接，正文和治理元数据分别消费，局部更新保留既有统计。 - 硬约束：文中内部 CodeBuddy 的 PreToolUse 钩子在索引未读时阻断 Read、Grep、Glob、Bash、mcp_call_tool、mcp_get_tool_description；重同步放 SessionStart，每次调用前只做轻量检查。案例展示的阻断方式为退出码 2，不能据此推定所有客户端兼容。
- 成熟度：阅读是弱信号，实际采用及验证声明是强信号。首次采用可进入 verified，至少两次采用且覆盖两个场景可进入 proven；另有 draft、archived。增量聚合按会话与路径去重，维护偏移和前缀哈希。衰减周期为 navigation 6 个月、decision 9 个月、pitfall/process 12 个月、model 18 个月；重复扫描不应加速衰减。日志超过 1 MB 轮转，保留最近 3 份。
- 等待与验收：平台访问、代码提交、等待、本地验证四类 Skill 组合。等待应绑定目标分支的特定构建，到成功、失败或超时才判断；检查者依据工件给出精确问题，工具权限限制其修改能力。
- 返工限制：团队流程中编码与审查、验证与编码、生效验证与编码分别最多往返 3 轮；返工后重新通过完整检查链。不能把未验证或阻塞状态包装成成功。
轻量统计由 maturity-lint 增量处理，只提升等级；周期性的 cleanup-knowledge-base 才做全库整理与衰减。读取日志 kb-usage.log 和采用声明 kb-refs.log 分开，检查点失败须明确报告。文中提交流程还要求先取得需求或缺陷单号，分别用 --story / --bug 关联。
摘录
仅保留短引文；其余内容为转述。
一律”定点修改”
按正确的维度等待
涉及实体
- 知识库工程、Agent-Memory —— 索引导航、引用信号与经验治理
- Hook-机制、Agent-Skill —— 强制前置条件与能力组合
- Loop-Engineering、Generator-Evaluator —— 等待终态、独立检查及返工控制
- Harness-Engineering —— 将以上机制组合成可追溯交付
涉及主题
我的评注
原文一处要求验证只在测试环境进行，后续又描述线上验证，未解释二者的操作边界；采用时须明确主动测试与发布后观察的区别。文中的提交、MR 合入和发布是一套特定团队流程，不能据此扩展用户授权。使用次数是治理信号，知识是否仍然正确还需检查证据与版本。