AI 工程操作系统：工具只是入口

专业性不在于会用某个 AI 工具，而在于能不能把工具组织成稳定的交付系统：任务有入口，规则有承载，执行有边界，验证有闸门，经验能沉淀。

很多人展示 AI 能力时，会停在“我会用 Claude Code / Codex 写代码”。这不够。工具名称会变，模型能力会变，真正可迁移的是一套工作系统：它能把模糊需求转成规格，把规格拆成工作单，把 AI 输出放进验证闭环，再把交付过程沉淀成下一次的资产。

本站把这套系统称为 AI 工程操作系统。它不是一个产品，而是一组围绕交付闭环工作的工程设施。

一、定位：从工具使用到工程系统

AI 工具可以分三层看：

层级	关注点	专业表达
工具层	用什么入口执行任务	Claude Code / Codex / IDE Agent / CLI Agent
方法层	用什么流程约束产出	需求体检、规格、工作单、代码审查、验证清单
组织层	如何让能力可复用	Skills、Rules、Hooks、Memory、ADR、缺陷库、多 Agent 编排

如果只停在工具层，能力很容易被理解成“会操作软件”。如果能讲清方法层和组织层，读者看到的就是另一件事：这里讨论的不是某个工具的熟练度，而是一套可以持续产出代码、测试、文档和决策记录的交付环境。

二、组件分层：每个工具都有职责边界

组件	负责什么	不负责什么
Claude Code / Codex	作为代码理解、修改、验证和执行编排入口	不替代业务判断，不替代结构性决策
Rules / CLAUDE.md / AGENTS.md	固化项目红线、架构边界、编码规范和验收纪律	不承载长流程，避免常驻上下文过重
Skills	固化高频流程：需求体检、TDD、Review、验证、复盘	不存放一次性项目事实
Hooks / Scripts	把必须执行的动作机器化：格式化、测试、提交前检查	不自动批准高风险动作
Memory / ADR	保存项目事实、结构决策和长期经验	不保存未经验证的临时猜测
多 Agent	为需求、架构、实现、测试、Review 提供独立上下文	不用于低风险小改，不用于澄清混乱需求

这张表的重点不是列工具，而是说明边界。一个专业的 AI 工作流，首先要知道哪些事情可以交给工具，哪些事情必须由人判断。

三、常用 Skill：把经验变成可复用流程

Skill 的价值不是“多装几个能力包”，而是把可重复的工程动作压缩成稳定步骤。我的 Skill 设计通常按交付链路分组：

Skill 类型	解决的问题	产物
需求体检	AI 最容易替人脑补默认假设	缺口清单、待确认问题、风险分级
规格生成	把口头需求转成可测试规则	行为规格、边界条件、验收标准
工作单生成	防止任务范围漂移	输入、范围、禁区、验收标准、输出格式
测试设计	防止只覆盖 happy path	失败用例、边界用例、回归清单
Code Review	用独立视角审查实现	问题清单、风险裁决、修复建议
缺陷复盘	把一次失败变成下一次防线	缺陷模式、规则更新、模板更新

Skill 本质上是把“我知道应该怎么做”变成“系统每次都会这么做”。这比临场 prompt 更稳定，也更能体现工程成熟度。

四、多 Agent 协同：不是人数多，而是上下文独立

多 Agent 的目标不是显得复杂，而是让关键职责相互独立：

角色	输入	输出	独立性的价值
产品审查 Agent	原始需求、业务目标	缺口、取舍点、验收疑问	防止一上来就写代码
架构 Agent	规格、存量约束	模块边界、数据模型、接口契约风险	防止实现细节绑架结构决策
实现 Agent	工作单、禁区、验收标准	代码改动、实现说明	在明确边界内提高产出速度
测试 Agent	规格和风险清单	能失败的测试、未覆盖说明	防止实现者自证正确
Review Agent	规格 + diff	缺陷清单、边界违反、回归风险	用干净上下文打破自写自审
复盘 Agent	缺陷、修复、测试结果	规则更新、缺陷库、模板改进	把经验沉淀为资产

这里最重要的是 干净上下文。实现 Agent 的对话历史里可能已经包含错误假设，Review Agent 不能继承这些假设。它只读规格和 diff，像一个没有参与实现过程的 reviewer。

五、成本纪律：什么时候不用 AI 编排

专业不是把所有任务都流程化，而是会算账。

任务类型	推荐方式	原因
文案、样式、小范围重命名	单会话直接做	编排成本高于风险
涉及数据写入、权限、接口契约	工作单 + 独立 Review	需要控制边界和回归
涉及资金、并发、一致性、核心链路	需求审查 → 架构 → 实现 → 测试 → Review → 回归	缺陷逃逸代价高于编排成本
需求仍然混乱	先需求体检，不并行	多 Agent 会放大不同默认假设

这也是判断 AI 能力是否成熟的关键：不是“能不能让 AI 做更多”，而是“知道什么时候不该让 AI 自主推进”。

六、对外协作：先讲系统，再讲工具

对外说明 AI 工作方式时，重点不应先落在“用了哪个工具”，而应该落在工作系统：需求如何被澄清，边界如何被锁定，AI 如何被分配任务，产物如何被验证，经验如何回到资产库。

更准确的定位是：AI 是可编排的执行系统，而不是聊天工具。在复杂任务里，先做需求体检和规格定义，再用工作单约束实现范围；实现、测试和 Review 分上下文执行，关键规则通过 Skills、Rules、Hooks 和 Memory 固化。这样 AI 不是随机生成代码，而是进入一条可验证、可复盘、可复用的工程链路。

这种表达不会把价值押在 Claude Code、Codex 或某个具体平台上。平台只是入口，真正的价值在于工程管理、风险控制和资产沉淀能力。

七、和本站其他页面的关系

• Agent 执行：说明人机决策权如何划分；
• Agent 工作单：说明如何把任务写成可执行任务卡；
• 多 Agent 编排：说明独立上下文如何组成流水线；
• 工具工作台：说明工具如何分梯队引入；
• Harness 实录：展示这套操作系统在个人工作台里的真实安装方式。

这一页的作用，是把工具名、流程、Agent 和工程资产放到同一个框架里：AI 能力不是某个工具的熟练度，而是系统化交付能力的放大器。