把 Codex 变成工程认知系统：如何沉淀 Rules、Skills、Context、Architecture 与工程经验

关注

原创最新推荐文章于 2026-10-22 09:59:07 发布 232 阅读 AI 写同款· GEO 优化 ›

AI工程化技能协议：用mattpocock/skills校准大模型输出在AI编程实践中，'能生成代码'不等于'能交付可靠软件'——核心瓶颈已从模型能力转向工程对齐能力。工程化技能协议（Engineering Skill Protocol）是一种运行在提示层的轻量框架，通过结构化对齐、原子化任务分解与领域知识注入，将模糊需求转化为可评审、可测试、可追踪的交付单元。它不依赖特定模型，却显著提升GPT-4、Claude 3.5、DeepSeek v4 Pro等主流大模型的输出质量与工程可信度；典型应用场景包括需求转GitHub Issue、AI协同TDD、技术债定向重构及跨团队语义阅读详情

引言：AI 时代真正应该积累什么？

进入 AI 编程时代之后，很多开发者都在追逐更强的模型：

GPT、Claude、Codex，以及下一代更强的 Agent。

模型越来越强，代码生成越来越快，但这里面有一个容易被忽略的问题：

模型的能力可以租用，但工程认知必须自己拥有。

今天使用 Codex，明天可以换 Claude；今天使用一个模型，明天可以换另一个模型。

真正应该长期积累的，并不是某个模型本身，而是那些能够跨模型、跨平台、跨项目版本持续复用的东西：

Rules
Skills
Context
Architecture
Decisions
Failure Cases
Verification
Personal Knowledge

这些东西共同构成一个人的工程认知资产。

因此，使用 Codex 的目标不应该只是：

“让 AI 帮我把代码写出来。”

而应该逐渐变成：

“让 AI 在帮我写代码的同时，把这次工作的工程知识沉淀下来，让下一次工作更快、更准。”

这就是本文要建立的核心体系。

一、不要把 Codex 当聊天机器人

最基础的 AI 编程模式是：

人
 ↓
提问
 ↓
AI
 ↓
答案
 ↓
结束

这种模式最大的问题是：

每次工作都是一次性的。

例如：

这次遇到 Renderer 崩溃
        ↓
Codex 分析
        ↓
修好了
        ↓
会话结束

下一次遇到类似问题，AI 很可能还要重新分析。

于是你每一次都在重新支付相同的认知成本。

更高级的模式应该是：

                  ┌── Rules
                  ├── Skills
                  ├── Context
                  ├── Architecture
                  ├── Decisions
                  ├── Failure Cases
                  └── Verification
                         ↑
                         │
                      Codex
                         ↑
                         │
                       任务

Codex 不只是执行任务的工具，而是：

你的工程认知系统的推理引擎。

二、第一层：Rules

Rules 解决的问题是：

“这个项目应该遵守什么规则？”

例如：

修改 Mojo interface 必须同步检查 Browser / Renderer 两侧。

修改 generated code 之前，先确认源文件。

涉及 Renderer lifecycle 的修改必须补回归测试。

不要为了让编译通过随意改变线程模型。

未经确认不要修改第三方源码。

这些内容有一个共同特点：

它们相对稳定，而且需要长期遵守。

因此应该放进：

AGENTS.md
rules/

例如：

.ai/
├── AGENTS.md
└── rules/
    ├── coding.md
    ├── build.md
    ├── ipc.md
    └── testing.md

Rule 的判断标准非常简单：

如果你发现自己经常对 AI 说“以后不要这样做”，就应该考虑把它沉淀成 Rule。

三、第二层：Skills

Rules 是：

“不能做什么。”

Skills 是：

“应该怎么做。”

例如一个 Chromium Crash Analysis Skill：

Crash
 ↓
Call Stack
 ↓
Process
 ↓
Thread
 ↓
Object Lifetime
 ↓
Ownership
 ↓
IPC Boundary
 ↓
Root Cause
 ↓
Fix
 ↓
Regression Test

以后再遇到类似问题，不需要重新设计分析方法。

Skill 可以逐渐形成：

skills/
├── crash-analysis/
├── ipc-analysis/
├── mojo-analysis/
├── renderer-lifecycle/
├── gpu-debug/
├── build-debug/
└── git-recovery/

Skill 是非常高价值的资产，因为它沉淀的不是某一个问题的答案，而是：

解决一类问题的方法。

四、第三层：Context

Context 解决的是：

“这个项目现在到底是什么状态？”

例如：

项目基于 Chromium 132。

存在大量 360 自研修改。

Browser / Renderer / GPU 之间存在特定边界。

当前分支正在进行 Chromium 版本升级。

某些模块存在历史兼容逻辑。

当前构建使用特定 GN args。

这些内容属于：

context/
├── project.md
├── current-branch.md
└── module-map.md

但是这里有一个非常重要的原则：

不要把完整聊天记录当成长期 Context。

一个几万 token 的会话，并不等于高质量知识。

真正应该做的是：

Conversation
    ↓
Extract
    ↓
Context
    ↓
Architecture
    ↓
Decision
    ↓
Failure Case
    ↓
Knowledge

换句话说：

会话是原始数据，知识才是最终资产。

五、第四层：Architecture

这是工程知识体系里最重要的一层之一。

例如 Chromium：

Browser Process
        │
        ├── WebContents
        │
        ├── RenderProcessHost
        │
        └── RenderFrameHost
                 │
                 ↓
          Renderer Process
                 │
                 ├── Blink
                 ├── V8
                 └── RenderFrame

真正重要的不只是：

“这个类在哪里。”

而是：

“这些对象为什么存在，它们之间是什么关系？”

例如：

谁拥有谁？
谁创建谁？
谁销毁谁？
哪一侧负责生命周期？
IPC 从哪里到哪里？
Process 和 Frame 的关系是什么？
Restart 时哪些对象还活着？
哪些状态可以跨进程保留？

这些才是工程开发中最核心的 Mental Model。

因此：

architecture/
├── process-model.md
├── browser-renderer.md
├── mojo.md
├── navigation.md
└── gpu.md

应该长期维护。

六、第五层：Decision Log

这是很多知识库最容易忽略的一层。

代码告诉你：

“现在是什么样。”

但 Decision 告诉你：

“为什么现在是这样。”

例如：

DEC-023

问题：
Transport 应该由 Browser 还是 Renderer 持有？

方案 A：
Renderer 持有 Transport。

方案 B：
Browser 持有 Transport。

最终选择：
B。

原因：
1. Renderer restart 不影响 Transport。
2. 生命周期更稳定。
3. IPC 边界更清晰。
4. 后续支持多 Renderer 场景更容易。

几年之后，新的开发者甚至 AI 看到代码，也能理解历史设计。

因此 Decision Log 实际上是在保存：

架构背后的因果关系。

七、第六层：Failure Cases

成功经验很重要，但：

失败经验往往更加值钱。

例如：

BUG-017

现象：
Renderer restart 后 Browser 仍向旧 Endpoint 发送消息。

错误方案：
Renderer 侧重新创建连接。

为什么错误：
Renderer 生命周期不稳定。

正确方案：
Browser 根据 RenderProcessHost lifecycle 重建连接。

关键认知：
IPC Endpoint 生命周期 != Process 生命周期。

适用场景：
Renderer crash / restart / recovery。

以后 Codex 再看到类似结构，就可以主动判断：

“这里是不是又存在历史 BUG-017 的风险？”

这就形成真正的经验复用。

八、第七层：Verification

很多 AI 编程的问题不是：

“代码不会写。”

而是：

“写完不知道怎么证明正确。”

因此必须把验证方式也沉淀下来。

例如：

Renderer Lifecycle 修改
        ↓
Build
        ↓
Unit Test
        ↓
IPC Test
        ↓
Renderer Restart Test
        ↓
Smoke Test

可以形成：

verification/
├── renderer.md
├── ipc.md
├── gpu.md
└── navigation.md

最终 Codex 的输出不应该只是：

“代码改完了。”

而应该是：

“代码改完了，并且按照这个 Verification Matrix 验证过。”

九、第八层：Personal Knowledge

还有一类知识不应该完全绑定在具体项目上。

例如你长期积累的：

C++
Chromium
Mojo
V8
GPU
OS
Networking
Concurrency
Memory Management
Browser Architecture

这些属于你自己的长期知识。

应该放在项目之外。

例如：

knowledge/
├── cpp/
├── chromium/
├── v8/
├── gpu/
├── networking/
├── os/
└── concurrency/

这样即使：

Chromium 132
    ↓
Chromium 148
    ↓
Chromium 160

你的知识仍然可以复用。

十、会话 Context 应该怎么处理？

一个真正高质量的 Codex 会话结束以后，不应该只留下：

chat history

而应该做一次：

Conversation
     ↓
Knowledge Extraction

把这次会话中的信息分类：

Rule
Skill
Context
Architecture
Decision
Failure
Verification

例如：

原始会话：

为什么 Renderer restart 之后 IPC 失效？

        ↓

提取：

Architecture
    Renderer ↔ Browser lifecycle

Decision
    Browser 负责重新建立 endpoint

Failure
    Renderer 持有 stale endpoint

Verification
    renderer_restart_test

Skill
    Renderer restart analysis

原来的几万 token 会话可能最终只需要留下几百字。

但这几百字可能比原始聊天记录更有价值。

十一、最终的 Codex 知识体系

比较推荐的目录结构：

.ai/
│
├── AGENTS.md
│
├── rules/
│   ├── coding.md
│   ├── build.md
│   ├── ipc.md
│   └── testing.md
│
├── skills/
│   ├── crash-analysis/
│   ├── ipc-analysis/
│   ├── renderer-lifecycle/
│   ├── gpu-debug/
│   └── git-recovery/
│
├── architecture/
│   ├── process-model.md
│   ├── browser-renderer.md
│   ├── mojo.md
│   ├── navigation.md
│   └── gpu.md
│
├── decisions/
│   ├── DEC-001.md
│   ├── DEC-002.md
│   └── ...
│
├── failures/
│   ├── BUG-001.md
│   ├── BUG-002.md
│   └── ...
│
├── verification/
│   ├── renderer.md
│   ├── ipc.md
│   └── gpu.md
│
└── context/
    ├── project.md
    ├── current-branch.md
    └── module-map.md

这套结构的核心不是“文档越多越好”。

而是：

每一次 AI 工作，都应该有机会让下一次 AI 工作变得更快、更准确。

十二、最终形成知识生命周期

最理想的状态是：

任务
 ↓
Codex
 ↓
发现新知识
 ↓
┌────────┬────────┬────────┐
│ Rule   │ Skill  │Decision│
└────────┴────────┴────────┘
          ↓
     Architecture
          ↓
      Failure Case
          ↓
      Verification
          ↓
     长期工程知识

于是：

第一次遇到问题
    ↓
成本较高

第二次遇到类似问题
    ↓
有 Skill / Architecture
    ↓
成本下降

第三次
    ↓
有 Decision / Failure Case
    ↓
进一步下降

长期
    ↓
形成自己的工程智能系统

这就是所谓的：

AI 编程的复利。

十三、最重要的原则

最终可以把整个体系压缩成一句话：

不要只让 Codex 帮你完成任务，要让 Codex 在完成任务的同时，把“为什么这么做、哪些方案不能做、以后遇到类似问题怎么做”留下来。

模型可以换。

平台可以换。

Agent 可以换。

但是：

你的 Rules
你的 Skills
你的 Context
你的 Architecture
你的 Decisions
你的 Failure Cases
你的 Verification
你的 Engineering Judgment

应该越来越丰富。

这才是真正属于你的 Personal AGI。

而 Codex 最理想的角色，不是替代你的工程认知，而是：

成为你工程认知的放大器。

收录于

chrome

人工智能

标签

#人工智能 #经验分享 #chrome

Claude Code（18）：mattpocock/skills 的安装与使用本文介绍了 Claude Code 代码生成中的常见问题及其解决方案——Matt Pocock 提出的 Skill 框架。该框架通过可单独启用的 Skill 解决四类核心问题：需求对齐（Grill）、术语混乱（CONTEXT.md）、代码质量（TDD）和架构退化（improve-codebase-architecture）。阅读详情