长期可持续的交付价值：与AI共同进化

长期可持续的交付价值：与AI共同进化

30天写完了，SKILL会写了，Agent能跑了，团队也开始用了。

但有一个问题始终悬在头上：这些东西能跑多久？

你今天花两周打磨的SKILL，同事拿过去也能跑——差距在哪？你今天写的references，三个月后还准吗？你今天的SKILL架构，需求翻倍后还撑得住吗？

30天进阶解决的是"从0到1"——把AI用起来。今天聊的是"从1到N"——如何让你和AI的协作关系，产生长期的、可持续的、别人难以复制的价值。

一、知识构建：你的上限不是AI的能力，是你喂给它的认知

一个容易忽视的事实

大部分人对SKILL的理解停在"写Prompt"。觉得SKILL就是一套指令模板，写好了AI就能干活。

这是一个危险的误区。

SKILL的本质不是指令，是知识。你对业务和技术的理解深度、对信息的蒸馏质量，决定了SKILL能交付的价值上限。同样一个"代码审查"SKILL，你写的和另一个人写的，区别不在Prompt技巧，在于你脑子里有多少关于代码质量的真实认知。

三种认知水平的产出差异：

初级认知（写Prompt）：
- SKILL内容：检查代码规范、命名风格、注释完整性
- 产出质量：能发现格式问题
- 瓶颈：只看表面，和lint工具没区别

中级认知（理解工程）：
- SKILL内容：基于项目的设计模式和架构约定做审查
- 产出质量：能发现违反架构约定的代码、潜在性能问题
- 瓶颈：规则是静态的，项目演进后规则失效

高级认知（蒸馏本质）：
- SKILL内容：
- 项目的核心架构决策和背后的trade-off
- 常见的"看起来对但实际会坑"的代码模式库
- 不同模块的质量敏感度分级（核心链路 vs 边缘功能）
- 产出质量：能发现"技术上没错但设计上有隐患"的问题
- 关键差异：蒸馏出来的是"判断框架"，不是"检查清单"

举个具体的例子：你的项目里有一个数据访问层，团队约定"所有数据库查询必须走Repository模式"。初级SKILL只知道检查有没有直接写SQL；高级SKILL理解为什么要走Repository——是为了统一缓存策略和读写分离——所以它还会检查绕过Repository的间接路径，比如通过ORM直接操作。

这个"为什么"就是蒸馏出来的知识，不是从代码规范文档里抄来的。

复利工作法：让知识自动增值

知识不是一次性构建的，是需要持续投入才能保持有效的资产。

第一层：信息采集（线性增长）
- 做法：每次CR、每次Bug修复、每次技术决策，记录关键信息
- 积累方式：case by case，量变
- 保鲜周期：信息本身3-6个月就可能过时
- 示例：
- 2026-03-15 用户模块引入GraphQL，替代部分REST接口
- 2026-03-20 React 19升级后，useEffect的cleanup行为变了
- 2026-04-01 引入Zod做运行时类型校验，替代手写validator

第二层：模式提炼（指数增长）
- 做法：从信息中提炼规律和模式
- 积累方式：N条信息 → 1条规律，规律之间互相验证
- 保鲜周期：模式通常1-2年有效
- 示例：
- 规律："跨模块的接口变更，必须同时更新上下游的类型定义"
- 规律："引入新依赖超过3个使用方时，值得封装一层适配层"
- 规律："涉及并发状态的代码，先写测试再改逻辑，反过来必翻车"

第三层：判断框架（复利增长）
- 做法：从模式中抽象出判断框架
- 积累方式：框架越用越准，每次使用都在校准
- 保鲜周期：框架本身长期有效，只需更新参数
- 示例：
- 框架："代码审查优先级 = 模块核心度 × 变更类型风险 × 测试覆盖度"
- 核心链路的接口变更 + 没有单测覆盖 = 必须仔细Review
- 边缘功能的样式调整 + 有快照测试 = 快速通过
- 这个框架不会过期，但里面的"哪些是核心链路"需要定期校准

真正的复利发生在第三层。第一层谁都能做——拿到SKILL照着跑，积累的也是同样的信息。第二层需要思考——别人拿着你的SKILL跑，不一定能提炼出同样的模式。第三层是你的护城河——判断框架是从大量实战中内化出来的，无法简单copy。

知识保鲜：防止SKILL里的认知腐烂

技术栈在演进，框架在升级，团队约定也在变。你的SKILL如果不跟着更新，过时的知识比没有知识更危险——AI会用过时的规则自信地给出错误建议。

问题：SKILL中的references写了20条技术规范和设计约定，半年后其中5条因为框架升级已经过时，3条因为架构调整需要微调 → AI拿着旧规范审查新代码，输出反而误导开发者。

保鲜策略：

1. 标注时效（每条知识标注有效期和来源）

格式示例：
- 规则：所有API接口必须用Zod做入参校验
- 来源：2026-03技术评审决议
- 有效期：长期
- 最后验证：2026-04-01

格式示例：
- 规则：前端状态管理统一使用Zustand，不引入Redux
- 来源：2026-01架构决策
- 有效期：至下次状态管理方案评审
- 最后验证：2026-03-15

2. 变更信号触发校验

当你发现AI的输出和预期不符时：
→ 先检查是不是references中的知识过时了
→ 常见触发场景：框架大版本升级、团队架构调整、新规范发布
→ 标记需要更新的知识条目，集中处理

3. 定期Review（月度知识巡检）

每月花1小时检查references：
→ 哪些已过时？删除或更新（框架升级、API废弃）
→ 哪些缺失？补充新发现的模式（近期踩过的坑）
→ 哪些模糊？用最新案例强化描述

关键洞察：你的SKILL被别人拿走跑，短期差距不大——大家都在用同一个模型。但三个月后差距会拉开，因为你持续在喂认知、做蒸馏、保鲜知识，而别人只是在跑你留下的"快照"。知识的时效性，决定了SKILL的生命力。

二、信息的渐进式披露：精细化设计你的references

references怎么切，是最难的实操问题

Progressive Disclosure我们在Day27就讲过——三层加载：metadata、SKILL.md body、references。原理大家都懂，但实操中最难的是references怎么切。

常见的三种设计误区：

误区1：一个大文件塞所有信息
-references/all_rules.md→ 8000行
- 问题：
- 每次加载全量，大量上下文被浪费
- AI在长文本中注意力衰减，真正重要的信息反而被忽略
- 你以为给得多AI就做得好，实际上给得多AI反而做得差

误区2：按代码模块切分
-references/payment.md、references/user.md、references/order.md
- 问题：
- 看起来整齐，但实际任务往往跨多个模块
- 一个"用户下单"的场景要同时加载user + order + payment
- 要么加载不全遗漏信息，要么全量加载回到误区1

误区3：切太细，粒度失控
-references/payment_create.md、references/payment_verify.md、references/payment_callback.md...（30个文件）
- 问题：
- SKILL.md中要维护复杂的路由逻辑来决定加载哪些文件
- 路由逻辑本身可能出错，加载错文件比不加载更糟
- SKILL变复杂了，本末倒置

核心原则：按"决策场景"切分，不按"知识分类"

关键思维转换：references的切分维度不是"这些知识属于什么分类"，而是"AI在什么场景下需要这些知识来做决策"。

以一个"代码审查SKILL"为例：

按知识分类切（不推荐）： references/ ├── coding_standards.md # 编码规范 ├── architecture_rules.md # 架构规则 ├── security_checklist.md # 安全检查项 └── performance_tips.md # 性能优化建议 问题：审查一个API接口时，需要同时看编码规范+架构规则+安全检查 三个文件都要加载，但每个文件中只有一小部分和当前场景相关 按决策场景切（推荐）： references/ ├── api_review.md # 场景：审查API接口代码 │ 内容：接口设计规范 + 入参校验要求 + 安全约束 + 性能基线 │ → 审查API时加载这一个文件就够了 │ ├── data_model_review.md # 场景：审查数据模型和数据库变更 │ 内容：模型设计原则 + 索引规范 + 迁移安全规则 │ ├── frontend_review.md # 场景：审查前端组件和页面逻辑 │ 内容：组件设计规范 + 状态管理约定 + 可访问性要求 │ └── dependency_review.md # 场景：审查依赖引入和升级 内容：依赖准入标准 + 版本策略 + 安全审计要求 好处：每个场景一个文件，加载精准，上下文干净

再看一个"技术方案生成SKILL"的例子：

按决策场景切分： references/ ├── quick_assessment.md # 场景：快速评估方案可行性 │ 内容：技术选型决策树 + 团队技术栈清单 + 已有基础设施 │ 用途：2分钟内判断"这个方案能不能做、用什么技术做" │ ├── detailed_design.md # 场景：输出详细技术设计 │ 内容：模块划分原则 + 接口设计规范 + 错误处理约定 │ 用途：生成可Review的技术方案文档 │ ├── tradeoff_analysis.md # 场景：方案选型需要对比多个选项 │ 内容：团队历史技术决策 + 选型评估维度 + 踩坑记录 │ 用途：不是选"最好的"方案，是选"最适合团队的"方案 │ └── review_checklist.md # 场景：方案写完后自查 内容：方案完整性检查项 + 常见遗漏点 + 评审要点

如何验证切分效果

切分完不是结束，你需要验证这份reference是否真的帮到了AI。很多人凭直觉"这应该有用"就塞进去，从没验证过。

A/B对比测试步骤：

1. 准备5个真实的历史任务（比如5个已完成的CR记录）
2. 不加载reference，让AI做一遍 → 记录输出质量
3. 加载reference，让AI再做一遍 → 记录输出质量
4. 对比两次输出

判断标准：
-有效：加载后输出质量明显提升
→ 发现了更多有价值的问题
→ 建议更具体、更贴合项目实际
→ 减少了"正确但没用的废话"
-无效：加载前后差异不大
→ 这份reference可能是"噪音"——AI本来就知道这些通用知识
→ 删除它，节省上下文空间
-负效果：加载后反而变差
→ 信息量太大导致注意力分散
→ 或者信息和AI的内置知识冲突，造成混乱
→ 精简内容，只保留AI不知道的、项目特有的知识

实际数据参考：
- 有效的reference → 输出质量提升20-40%
- 过长的reference（超过3000行）→ 大概率出现注意力衰减
- 最优区间 → 单个reference 500-1500行，聚焦单一决策场景

粒度校准：你处在哪个阶段决定了最优粒度

大部分SKILL的生命周期：先用粗粒度跑通验证价值 → 积累一段时间后发现哪些场景用得多 → 按高频场景拆成中粒度 → 只有极少数需要细粒度。

关键洞察：references不是文档库，是决策燃料。每份reference的价值不在于它包含多少信息，而在于它在特定决策场景下能带来多大的增量效果。切分的标准是"AI拿到这份信息后，判断力提升了多少"——如果提升不明显，删掉比留着好。

三、SKILL优化与迭代：从"能跑"到"跑得久"

SKILL是怎么腐化的

SKILL跑一段时间后，你会发现一个规律：每次为了兼容一个新场景、修一个edge case，SKILL就变臃肿一点。

这跟代码腐化是一样的道理，但SKILL的腐化更隐蔽——代码腐化有lint告警、有测试失败，SKILL腐化的表现是"输出质量悄悄变差"。

V1.0（干净）：
- 核心逻辑：帮助开发者做Code Review
- 行数：150行
- 质量：聚焦、清晰，AI知道自己该干什么

V1.1（兼容前端场景）：
- 新增："如果是React组件，额外检查hooks规则和状态管理"
- 行数：200行
- 状态：开始出现条件分支，但还可控

V1.2（修复误判）：
- 新增："如果是测试文件，不要检查注释规范"
- 新增："如果文件名包含mock，跳过类型检查"
- 行数：250行
- 状态：例外规则越来越多，主干逻辑开始被淹没

V1.5（兼容多语言）：
- 新增：Python后端审查规则、Go微服务审查规则
- 行数：400行
- 状态：Java、Python、Go、TypeScript的规则混在一起，AI有时候会用TypeScript的规则审查Python代码

V2.0（该重构了但没重构）：
- 结果：SKILL变成了一团"意大利面条"
- 新人看不懂，老人不敢改，只能继续打补丁
- → 这就是SKILL腐化

分层架构：基础逻辑和业务定制逻辑分开

解法不是"写得更小心"，而是架构层面把不变的和常变的分开。

第一层：基类SKILL（稳定层，很少改动）
- 职责：所有SKILL共享的执行框架和质量约束
- 变更频率：低（月级别）
- 包含内容：
- 输入校验：确保任务描述、代码片段等必要信息完整
- 执行流程：理解需求 → 分析代码 → 输出结论 → 自检
- 输出格式：结构化、有依据、可追溯
- 质量约束：不确定时说"不确定"而非编造、引用具体代码行号
- 边界处理：信息不足时主动提问，而非猜测

第二层：业务SKILL（变化层，经常更新）
- 职责：特定场景的规则、知识、判断逻辑
- 变更频率：高（周级别）
- 示例：
- 代码审查SKILL：项目特有的架构约定、编码规范、审查重点
- 技术方案SKILL：团队的技术选型偏好、已有基础设施信息
- API设计SKILL：接口规范、错误码定义、版本策略

分层的好处：
1. 基类稳定，业务灵活
→ 更新代码审查的规范不影响执行框架
→ 升级执行框架的质量约束不影响业务规则
2. 新场景只改业务层
→ 新增Python审查支持：只需添加Python的业务规则
→ 不需要在基类中加if-else
3. 多个SKILL共享基类
→ 代码审查SKILL、技术方案SKILL、API设计SKILL
→ 共用同一套执行框架和质量约束
→ 一处升级输出格式，三个SKILL同时受益

沉淀测试用例：每次改动都有安全网

SKILL和代码一样，改了就要回归。但SKILL的测试有个独特难点——输出是非确定性的，同一输入不一定得到完全相同的输出。所以测试策略需要特殊设计：

类型1：Golden Case（必须通过的核心场景）
- 定义：SKILL的核心能力，输出必须满足硬约束
- 示例：
- "审查包含SQL注入风险的代码，必须标记为安全问题"
- "生成技术方案时，必须包含回滚策略"
- 验证方式：检查输出中是否包含关键结构化字段
- 数量：10-20个，覆盖SKILL的核心价值路径

类型2：Boundary Case（边界和异常场景）
- 定义：容易出错的边界场景
- 示例：
- "输入的代码片段只有3行时，不应该输出一份2000字的审查报告"
- "输入的代码语言和SKILL预期不一致时，应该提示而非强行审查"
- 验证方式：输出中包含特定关键词或满足长度约束
- 数量：5-10个，覆盖已知的坑

类型3：Regression Case（历史问题不复现）
- 定义：曾经出过问题的真实case
- 示例：
- "上次把测试代码标记为生产Bug的case，不能再犯"
- "上次忽略了并发安全问题的case，现在必须识别出来"
- 验证方式：对比历史错误输出，确认已修复
- 数量：持续积累，每次线上问题都新增一条

回归流程：
- 修改SKILL → 本地跑Golden Case（5分钟）
- → 全部通过 → 跑Boundary + Regression（15分钟）
- → 全部通过 → 提交
- → 任何失败 → 分析原因，修复后重跑

为什么这很重要？因为SKILL的一个微小修改——比如你在提示词里加了一句"注意安全问题"——可能会导致AI变得过度敏感，把正常代码也标为安全风险。没有回归测试，你不知道这个改动是改好了还是改坏了。

关键洞察：SKILL不是写完就放那里的静态文件，是一个活的系统。像维护代码一样维护SKILL——分层架构防腐化，测试用例防回归。SKILL的长期价值，取决于你的工程化维护水平。

四、SKILL自我迭代：让AI帮你发现优化方向

瓶颈：你的时间是有限的，case是无限的

到目前为止，SKILL的优化都依赖人——你发现问题、你分析原因、你改SKILL、你跑回归。

这个模式有瓶颈：你的时间是有限的，但SKILL每天产出的执行记录是海量的。

每天SKILL跑几十次，产出的执行记录、用户反馈、中间推理过程里，藏着大量优化线索。但你不可能每条都看。绝大部分执行数据就这么白白浪费了。

真正的进化，不是你一个人在推，是让AI帮你从数据中发现优化方向。

你手上已经有的数据

1. 执行记录
- 每次执行的输入和输出
- 执行耗时、token消耗
- 用户对输出的反馈：采纳了/手动修改了/直接拒绝了
- 价值：用户修改最多的地方 = SKILL最薄弱的环节

2. 推理过程
- Agent在每个阶段的中间推理
- 哪些references被加载了、哪些最终没被用上
- AI在哪些环节犹豫了（输出了"不确定""可能"等词）
- 价值：AI犹豫的地方 = references可能缺失或模糊

3. 异常和边界记录
- 幻觉被拦截的记录（Hard-Gate触发）
- 输出不符合格式要求的记录
- 用户中途打断重新提问的记录
- 价值：异常高频的场景 = 需要针对性强化的场景

利用Summary和Compact机制沉淀经验

Claude Code的conversation summary和context compact机制——在上下文即将溢出时，把关键信息压缩保留——这个机制不只是性能优化手段，它可以被主动利用来做经验沉淀。

步骤1：周期性汇总（每周或每两周一次）
- 输入：过去N天的SKILL执行记录
- 方式：让AI分析这些记录，识别模式
- 输出：
- 高频成功模式："生成API方案时附带示例代码，用户采纳率高30%"
- 高频失败模式："审查Go代码时经常遗漏goroutine泄漏风险"
- 新发现的场景："最近3次涉及WebSocket的审查都处理得不好"

步骤2：经验转化为SKILL改进建议

AI基于汇总结果，生成具体、可操作的改进建议：
- "references/api_review.md 中缺少WebSocket相关的审查规则，过去两周有3次WebSocket代码审查质量不达标"
- "Golden Case中缺少并发场景的测试，建议新增goroutine泄漏检测的回归用例"
- "references/frontend_review.md 的React hooks规则在v19后需要更新，最近两次React审查AI引用了已废弃的hooks模式"

步骤3：人工审核 → 落地改进

AI提建议，你做决策：
- → 确认有效的 → 更新SKILL，新增测试用例
- → 不确定的 → 加入Boundary Case观察一段时间
- → 明显不对的 → 拒绝，标记原因（帮助AI下次提更好的建议）

完整闭环：从日常使用到持续进化

日常使用 → 产出执行记录 + 用户反馈 + 异常日志 → 数据自然积累 周期汇总（每1-2周） → AI分析执行数据，识别模式 → 输出改进建议清单 人工审核（每次30分钟） → Review改进建议 → 决策：接受 / 观察 / 拒绝 SKILL更新 → 更新references或SKILL.md → 跑回归测试（Golden + Boundary + Regression） → 发布新版本 效果验证（下一个周期） → 对比新旧版本的执行指标 → 用户反馈是否改善 → 没改善 → 回滚 + 分析原因 持续循环 → 每个周期让SKILL准一点、全一点 → 复利效应：改进不断积累，三个月后回头看差距明显

这个闭环中最关键的一步是人工审核——AI可以提建议，但改不改、怎么改，决策权在你。不是因为不信任AI，而是因为SKILL的每次修改都会影响后续所有用户的使用体验，需要有人对结果负责。

关键洞察：SKILL的自我迭代不是"让AI自己改自己"，而是让AI做数据分析师，你做决策者。AI擅长从海量执行记录中发现模式和异常，你擅长判断这些发现是否值得固化成规则。两者配合，才是可持续的进化路径。

五、四个引擎的关系

把前面四个维度串起来，它们不是四个独立的事，是一个互相驱动的系统：

引擎1：知识构建（决定上限） ├── 对业务和技术的理解深度，决定SKILL的价值天花板 ├── 复利工作法：信息 → 模式 → 判断框架 └── 知识保鲜：标注时效 + 变更信号触发 + 月度巡检 引擎2：信息披露（决定效率） ├── references按决策场景切分，不按知识分类 ├── A/B验证：加载后AI判断力提升多少 └── 粒度平衡：500-1500行/文件，5-8个场景文件 引擎3：架构迭代（决定寿命） ├── 分层架构：基类SKILL（稳定）+ 业务SKILL（灵活） ├── 测试回归：Golden + Boundary + Regression三类用例 └── 多SKILL共享基类，一处升级多处受益 引擎4：自我进化（决定速度） ├── 利用执行数据做周期汇总，AI发现优化方向 ├── AI提建议，人做决策，闭环改进 └── 每个迭代周期让SKILL更准一点

四个引擎之间的驱动关系：

这四个引擎形成正循环：知识越好 → reference越准 → SKILL跑得越好 → 积累的数据越有价值 → 发现的改进方向越精准 → 知识进一步提升。

六、结语：AI时代的长期主义

回到开头的问题：这些东西能跑多久？

答案取决于你把自己定位成什么角色。

如果你是"SKILL使用者"——拿别人写好的SKILL跑，用别人沉淀的knowledge，那你的价值会随着AI工具的普及而递减。因为谁都能跑。

如果你是"知识工程师"——持续蒸馏业务认知、精细化设计信息披露、工程化维护SKILL架构、建立自我迭代闭环，那你的价值会随着时间的推移而递增。因为这些能力是用出来的，不是学出来的。

两种角色的价值曲线：

SKILL使用者：
- 短期：能用AI出活，效率提升明显
- 中期：AI工具普及，大家都能出活，差距缩小
- 长期：差异化消失，回到同一起跑线

知识工程师：
- 短期：前期投入大，搭建框架、沉淀知识、设计测试
- 中期：复利效应启动，SKILL越来越准，效率持续拉开差距
- 长期：判断框架 + 迭代闭环形成壁垒，别人很难追上

30天进阶到这里，我们覆盖了一条完整的路径：

• Week 1：学会写SKILL——让AI按你的规则输出
• Week 2：MCP + Agent——让AI连接世界、多步协作
• Week 3：Harness + 安全——让AI在约束中可靠运行
• Week 4：源码机制——理解AI决策的底层逻辑
• Day 26-30：实战进阶——不可替代性、知识复利、防幻觉、团队协同、生产执行
• 加餐篇：与AI共同进化——从"用AI"到"与AI共建长期价值"

这30天教给你的不是"怎么用Claude Code"，是怎么在AI时代构建可持续的技术竞争力。

工具会迭代，模型会升级，但有一件事不会变：能把AI的能力稳定地转化为业务价值的人，永远稀缺。

与AI共同进化，不是口号，是一种工作方式。从今天开始，每一次SKILL执行、每一条用户反馈、每一个踩过的坑，都是你和AI共同积累的资产。

让复利开始滚动。