>_hiveden.dev
文章GitHub

AI 编程之后，我开始重建自己的能力

能力单元系统插图

目的：明确"为什么要做这件事"、"做什么"、"做到什么程度算成功"。
这是项目的入口文档，其他文档（原则 / 设计 / 迁移）都从这里展开。

一、背景

1. 个人背景

我是第一批接触 coding agent 的开发者——从这类工具出现的早期就开始用，过去一年 100% 用 coding agent 生成代码。cc、Codex 是日常主力，加上一系列散落的 skill 和 prompt。这一年里：

  • 写代码的速度大幅提升
  • 不熟悉的库 / 框架可以快速上手
  • 重复的样板工作几乎不用自己写
  • 与此同时，对当前生态的各类问题也有了具体认识

按理说，工作量应该下降、项目复杂度应该可控。但实际经历恰恰相反。

用得越久，我越确信现在这套范式只是过渡形态。AI 编程的下一个形态还没真正出现，但能感觉到方向。这个项目除了整理眼下的混乱，也有为下一个形态做准备的意思，详见第 5 节。

2. 现状的悖论

按理说，AI 把写代码这件事大部分替我做了，工作量应该下降。实际不是。

写代码的速度确实快了。但 AI 写得越多，我审 diff、跑测试、对照需求、修补它漏掉的边界条件、整合进现有代码的时间也越多，加起来总量没减。

用 skill 是类似的故事。我装过不少 skill，每个都有阅读、试用、决定是否继续保留的成本。装到第 5 个的时候，光是记住哪个 skill 在什么场景下用、上次它出问题是什么原因，本身就是负担。

注意力的碎片化更糟。AI 让我可以 5 分钟换一个方向，代价是一天里在十个上下文之间来回跳，所谓"省下时间做核心判断"实际上被切得很碎。

跨项目复用本该是优势。但现在我有 3 个项目，3 套略不同的 cc hook，2 套略不同的 skill 配置，1 套已经过期没人维护。维护成本随项目数线性增长，复用率却在下降。

把这些放在一起看，结论大致是：AI 没让我的总工作量减少，只是把工作的内容换了。原来是写代码，现在是管理 AI 写的代码。后者比前者更耗注意力。

工作量之外，有件事让我更不安。

我做的越来越多——但我的能力越来越强吗？还是只是变成了一个 cc 转发员？

cc 写代码我转发给项目，cc 提方案我转发给团队，cc 解释概念我转发给同事。看产出，每天都在增加。但偶尔停下来问自己：项目里这个关键决策为什么这么做，离开 AI 我能讲清楚吗？没有 cc，重做这个项目大概要多久？面试或被同事追问时，每段代码我能 defend 吗？

这些问题我答不上来。回头看，过去一年我做出的东西大部分体现的是 cc 的能力，不是我自己的。

工作方式必须重新组织，原因就在这里。继续这样下去，我会做出越来越多的项目，但 cc 不可用、换了别的 AI、或者有人当面追问原理时，我没法独立应对。

3. 我在追问的核心问题

走到这一步，我意识到我面对的不是"如何更好地用 AI 工具"，而是几个更根本的问题：

  1. 如何封装我自己的编程能力？
    我做过的项目、踩过的坑、形成的判断和品味——这些"软知识"目前只存在于我的脑子里和某些项目的角落里。我没有方法把它们提取出来、复用起来、传承下去。

  2. 如何明确我自己能力的边界？
    AI 时代下，"我会什么"和"AI 会什么"越来越难分清。一个项目跑下来，哪些部分是我真的掌握的、哪些是 AI 替我代劳的？没有这个边界，我自己都不知道自己的真实水平。

  3. 如何在团队内迁移、拓展、迭代这些能力？
    即使我自己想清楚了，把"我的判断"传递给团队成员、让团队成员也能用 cc 高效协作，目前没有标准方式。每个人都在各自摸索，团队的能力沉淀几乎为零。

  4. 为什么现有的机制都解决不了？
    skill 系统、marketplace、各种 framework——我都试过了，越用复杂度越高，不解决根本问题。

4. 为什么现有机制做不到

我评估过当前主流方案，每一种都有结构性问题：

  • Anthropic Agent Skills / SKILL.md 系统：黑盒、加载不可控、执行不透明、无法评估。本质是"穿了目录结构外衣的 prompt 模板"——你不知道它什么时候被加载、加载后模型如何使用它、改了它有没有效果
  • Skill marketplace / registry（如 SkillNet、awesome-agent-skills 等）：解决"获得能力"，反而加剧"管理能力"的问题；每个引入都带未还清的认知债务——阅读、验证、维护、出错兜底的成本不会因为它"免费"而消失
  • Coding agent framework（Superpowers 等）：通用化设计无法承载个人 / 团队的具体业务规范，必须 fork 才能用——一旦 fork 又失去与上游同步的能力
  • Prompt-as-code 框架（DSPy 等）：解决 prompt 优化问题，不解决能力沉淀和复用问题
  • MCP server / 工具注册:解决工具可调用问题，不解决"我的判断怎么传递"的问题

共同问题：这些方案都默认人是消费方——人使用 AI 提供的能力、订阅 AI 设计好的工作流、套用 AI 给出的抽象层。我的需求正好相反：我想把自己的判断、品味、踩坑经验沉淀下来，让 AI 调用我沉淀的东西，而不是我去调用 AI 提供的现成方案。

5. 我看到的下一个形态

一年用下来，我能看到 AI 编程的下一个范式。它跟现在这套不一样——不是把当前形态做得更好，而是工作流的整体结构换了。

当前形态：

人 ↔ 通用 coding agent (cc / Codex / Cursor)
              ↓
          业务代码

现在的做法是：每个业务项目都要重新教 cc 一遍——讲架构、列约定、纠正它在这个项目里常犯的错。这些工作每开一个新项目就要再做一次，时间成本随项目数累加。一年下来光是教 cc 的时间就不是个小数目。

下一个形态：

人 → 定义 coding agent 框架 → 项目级定制 agent → 业务代码
                                    ↑
                          可插拔的能力单元（tools）
                          团队级 eval 机制

人不再在每个业务项目里重新教 cc，而是：

  1. 定义一个 coding agent 框架（一次性 / 周期性工作）
  2. 每个业务项目快速生成一个定制 agent——基于框架 + 项目所需的能力单元组合
  3. agent 本身已经知道业务规范（因为能力单元里写了），不需要每次重新引导
  4. 团队层面有 eval 机制审核 agent 产出质量

这套范式下：

  • 人的精力从业务项目里抽出来，回到框架层和能力单元层
  • 业务项目的开发真正接近"全自动"——因为定制 agent 已经知道这个项目需要什么、不能做什么
  • 团队有了沉淀和审核的载体——框架 + 能力单元 + eval 是可传递的资产，不再依赖个人记忆

这个项目在下一形态中的位置

这个项目是上述下一形态的基础设施之一——能力单元（capability unit）正是上图中"可插拔的能力单元"对应的工程化产物。

下一形态的组件对应本项目
可插拔的能力单元（tools）能力单元（capability units） ← 本项目核心
coding agent 框架未来项目（基于能力单元组合而成）
项目级定制 agent业务项目通过 cap install 组装
团队级 eval 机制能力单元中的 bin/check-all + 未来扩展

所以现在做能力单元这件事的意义在这里：它们就是下一形态里"项目级定制 agent"的零件。零件齐了，下一形态就是几个组合的问题。

实际工作流的运作设想

把上述抽象具体化，这套系统在日常开发中的形态：

抽取阶段（前期投入）：

  1. 从现有项目中识别可抽离的资产——cc hook、skill、经验、规范文档
  2. 抽离封装为独立的能力单元（独立项目、可测试、可复现）
  3. 明确每个能力单元的界限——does / does_not / 里程碑

集成阶段（业务项目侧）：

  1. 业务项目通过 caps.yaml 声明所需能力单元
  2. cap install 把能力单元拉到项目本地（gitignored）
  3. 启动 cc / agent 时，人显式指定用哪个能力单元处理什么任务

执行阶段（cc 协作）：

  1. cc 加载指定的能力单元（SKILL.md + 关联 docs + tools）
  2. 按确定性流程执行最小闭环：实现 → 测试 → 验证
  3. 人只在最后验收环节介入，按 checklist 审核

成熟形态：

  • 人只负责进入项目 → 启动业务项目定制 agent → 选择任务类别
  • agent 根据任务类别自动加载对应能力单元组合
  • 执行开发 / 迭代任务，输出工作报告
  • 人审核工作报告 → 点击通过

这个工作流的核心特征：

  • 人的精力前移：从"在项目里反复 hand-holding cc"变为"前期定义能力单元 + 末期审核工作报告"
  • 能力可复用：同一个能力单元跨多个业务项目共享
  • 流程可认证：每一步都有 verifier，不是黑盒
  • 审核可追溯：工作报告 + checklist 形成可审计的交付物

6. 我的思考的独特性

想清楚这件事的过程中，几个判断我觉得走在了当前讨论之前。

最关键的是认知预算这件事。SkillNet 之类的 marketplace 都在解决能力供给，但能力供给早就过剩了——我每天能装的 skill 远超我能消化的。真正稀缺的是我自己的注意力。

第二点是"我的能力 vs AI 的能力"这个边界。AI 厂商不会主动强调它，毕竟它和"AI 让你成为专家"的市场叙事冲突。但作为开发者，我长期不分清楚，会越来越不知道自己实际掌握什么。这一年我观察自己：能背的库 API 在减少（查 AI 就行），能讲清楚的架构权衡也在变少（方案是 AI 给的）。如果不主动建立边界，再过几年我可能连"自己什么都不会"这个事实都意识不到。

这个边界一画清，能力单元的设计取向就和主流分叉了。主流的 skill 几乎只考虑 AI 怎么消费它，人是事后的。我的设计反过来——能力单元首先是给人看的（教学、传承、迭代），其次才是给 AI 用的。

Runtime-agnostic 这条是吃过亏后的结论，不是设计偏好。Claude Code 的 skill、Cursor 的 rules 我都用过，绑定特定工具的资产，工具一变就报废。

三条所有权测试（能讲清楚、能答辩、能用 cc 重造）是我对"AI 时代下'我会'到底意味着什么"这个问题的回答。大多数关于 AI 工具的讨论都回避这个问题。

剩下两个是具体的设计决定。一是每个能力单元都要显式声明 does / does_not / opinionated_choices / when_to_fork——也就是承认它是有取舍的，可以被审视和 fork。主流的 skill 假装中立通用，但做任何事都有取舍，不如把取舍亮出来。二是能力单元应该分层（基础原子 → 团队约定 → 项目特异），让同一份能力既能广泛复用又能贴合具体场景。

这个项目要解决的问题

放到一起看，问题大致是这样：AI 让我能轻易拿到大量产出——代码、方案、文档、解释。但拿到产出和自己掌握是两回事。一年下来这个差别变得很清楚。

这套系统是为了让"自己掌握"在 AI 时代还能成立。能力单元就是工程化的容器，每个容器都要通过三条测试（讲得清、答得出、用 cc 能重造）。其他文档展开容器怎么设计、怎么实施。

二、问题陈述

三个根本问题，按重要性排序：

  1. 散落资产无法跨项目复用——每次新项目从零开始，或者复制粘贴 + 漂移
  2. 个人专长无工程载体——你的判断、品味、踩坑经验留在脑子里和 README 角落里，没法被自己未来调用，更没法被 AI 调用
  3. AI 与个人能力没有可控的协作方式——要么让 AI 全权做主（失控），要么完全不用 AI（浪费杠杆）

三、项目目标

主目标

把散落资产重组为"能力单元"——一种独立软件项目级别的、可复用的、个人 own 的工程载体。

三个子目标

  1. 可重造性：每个能力单元必须满足"我能讲清楚 / 能答辩 / 能用 cc 快速重造"
  2. 可调用性：业务项目能像引用依赖一样引用能力单元；agent 能按任务粒度精确加载其中的部分
  3. 可维护性：系统本身的复杂度足够低，能维护十年；不会因为换工作、换工具、换语言就推倒重来

明确的非目标

以下都不是本项目要做的：

  • 分布式 / 多人协作系统
  • skill marketplace / registry
  • 通用 AI agent framework / DSL
  • Web UI / dashboard / 监控
  • 多 agent 自动编排
  • 自动化 prompt 优化（DSPy 类）

四、项目价值

直接价值

  • 本地散落资产整洁化、版本统一
  • 新业务项目启动成本降低（已有能力直接 cap install）
  • 关键工作流（视频制作、表单实现等）有了可重复的标准

累积价值

  • 个人专长被工程化——可以被自己、团队、AI 高效复用
  • 建立"我的能力 vs AI 的能力"清晰边界
  • 多 runtime 兼容——换 cc / Cursor / 自研 agent 都不影响

长期沉淀的价值

  • 形成可继承、可教学、可演化的个人能力资产库
  • 工具变化时（cc 演化、新 agent 出现），只需更换 adapter，资产本身不动

五、关键决策

决策维度选择替代方案选择理由
能力单元定位独立软件项目全局 skill / prompt 集可独立测试、版本管理、跨 runtime
安装机制git tag + clone（gitignored）npm / submodule / monorepo语言无关、零基础设施
加载机制人显式指定路径自动 description 匹配可控、不污染上下文
Runtime 耦合runtime-agnostic绑定 cc工具会变，资产不变
工作流表达bin/ 脚本 + docs/ markdown独立 schema 文件能 code 的就 code，prose 是不确定性的来源

六、成功标准

阶段成功

  • 完成第 1 个能力单元的完整迁移
  • 在 1 个真实业务项目中通过 cap install 安装并使用
  • cc 能按 SKILL.md 完成一次端到端任务
  • 三条所有权测试通过

项目成功

  • 至少 3 个能力单元迁移完成
  • 至少 2 个业务项目使用 cap 系统
  • 整理散落资产的工作量减少 50% 以上
  • 无任何反模式清单中的事项被引入

长期成功

  • 工具切换时（如 cc → 新 agent），能力单元资产 100% 复用
  • 系统持续在用、持续在维护，没有被废弃
  • 个人 INVENTORY 中至少 5 个 unit 处于 full ownership 状态

七、风险与对策

风险概率影响对策
过度设计高严重严格遵守反模式清单；任何新设计需通过"它解决了什么具体问题"测试
一次想做太多高严重一次只做一个 unit 的初版搭建；让真实使用驱动下一轮迭代
引入过多外部 skill中中默认自建；引入需完全内化（讲清楚 + 答辩）
迁移中"顺手扩散"中中每次迁移只动当前 unit 的范围；其他散落不动
AI 工具变化导致返工低低runtime-agnostic 设计，工具变化只影响 adapter，不影响 unit

八、里程碑

Milestone 1：第一个能力单元跑通

  • 选择高频资产作为第一个 unit（候选：remotion-video）
  • 完成迁移流程的 6 个 Step（详见 03-MIGRATION）
  • 在一个业务项目里验证通过

Milestone 2：业务项目集成 + 多 unit 共存

  • 业务项目侧的 cap install 工作流跑顺
  • 第 2、3 个能力单元迁移
  • 第一次月度 review，更新 INVENTORY

Milestone 3：稳态运行

  • 高频资产基本迁移完成
  • 形成本地的 ~/capabilities/ 个人资产库
  • 工作流定型：开发 → 验收 → 沉淀

九、文档导览

本项目共 4 份文档，按顺序阅读：

  1. 00-CHARTER.md（本文档）：为什么 / 做什么 / 成功标准
  2. 01-PRINCIPLES.md：核心原则与反模式（纪律文档，必读）
  3. 02-DESIGN.md：系统设计与技术规范
  4. 03-MIGRATION.md：实施计划与完整示例

移交给 cc 的注意事项

  • 01-PRINCIPLES 是硬约束，所有设计和实现必须不违反
  • 第三节"反模式清单"是雷区清单，任何看似合理的扩展都要先对照检查
  • 一次只做一件事，不要在一个迁移中并行处理多个 unit
  • 遇到"是否要加 X"的诱惑时，永远回到 PRINCIPLES 自问

文档版本

  • v0.1：多轮讨论收束后的初版
  • 修订原则：只做减法，不轻易加字段