长期可持续的交付价值与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-152. 变更信号触发校验当你发现AI的输出和预期不符时→ 先检查是不是references中的知识过时了→ 常见触发场景框架大版本升级、团队架构调整、新规范发布→ 标记需要更新的知识条目集中处理3. 定期Review月度知识巡检每月花1小时检查references→ 哪些已过时删除或更新框架升级、API废弃→ 哪些缺失补充新发现的模式近期踩过的坑→ 哪些模糊用最新案例强化描述关键洞察你的SKILL被别人拿走跑短期差距不大——大家都在用同一个模型。但三个月后差距会拉开因为你持续在喂认知、做蒸馏、保鲜知识而别人只是在跑你留下的快照。知识的时效性决定了SKILL的生命力。二、信息的渐进式披露精细化设计你的referencesreferences怎么切是最难的实操问题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对比测试步骤准备5个真实的历史任务比如5个已完成的CR记录不加载reference让AI做一遍 → 记录输出质量加载reference让AI再做一遍 → 记录输出质量对比两次输出判断标准-有效加载后输出质量明显提升→ 发现了更多有价值的问题→ 建议更具体、更贴合项目实际→ 减少了正确但没用的废话-无效加载前后差异不大→ 这份reference可能是噪音——AI本来就知道这些通用知识→ 删除它节省上下文空间-负效果加载后反而变差→ 信息量太大导致注意力分散→ 或者信息和AI的内置知识冲突造成混乱→ 精简内容只保留AI不知道的、项目特有的知识实际数据参考- 有效的reference → 输出质量提升20-40%- 过长的reference超过3000行→ 大概率出现注意力衰减- 最优区间 → 单个reference 500-1500行聚焦单一决策场景粒度校准你处在哪个阶段决定了最优粒度粒度优点缺点适用阶段粗1-3个大文件路由简单不易遗漏上下文浪费大注意力衰减SKILL刚起步先跑通再说中5-8个场景文件按需加载上下文干净需设计路由逻辑SKILL成熟期推荐方案细15个小文件极致精准加载路由复杂维护成本高超大型SKILL多团队协作大部分SKILL的生命周期先用粗粒度跑通验证价值 → 积累一段时间后发现哪些场景用得多 → 按高频场景拆成中粒度 → 只有极少数需要细粒度。关键洞察references不是文档库是决策燃料。每份reference的价值不在于它包含多少信息而在于它在特定决策场景下能带来多大的增量效果。切分的标准是AI拿到这份信息后判断力提升了多少——如果提升不明显删掉比留着好。三、SKILL优化与迭代从能跑到跑得久SKILL是怎么腐化的SKILL跑一段时间后你会发现一个规律每次为了兼容一个新场景、修一个edge caseSKILL就变臃肿一点。这跟代码腐化是一样的道理但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-else3. 多个SKILL共享基类→ 代码审查SKILL、技术方案SKILL、API设计SKILL→ 共用同一套执行框架和质量约束→ 一处升级输出格式三个SKILL同时受益沉淀测试用例每次改动都有安全网SKILL和代码一样改了就要回归。但SKILL的测试有个独特难点——输出是非确定性的同一输入不一定得到完全相同的输出。所以测试策略需要特殊设计类型1Golden Case必须通过的核心场景- 定义SKILL的核心能力输出必须满足硬约束- 示例- 审查包含SQL注入风险的代码必须标记为安全问题- 生成技术方案时必须包含回滚策略- 验证方式检查输出中是否包含关键结构化字段- 数量10-20个覆盖SKILL的核心价值路径类型2Boundary Case边界和异常场景- 定义容易出错的边界场景- 示例- 输入的代码片段只有3行时不应该输出一份2000字的审查报告- 输入的代码语言和SKILL预期不一致时应该提示而非强行审查- 验证方式输出中包含特定关键词或满足长度约束- 数量5-10个覆盖已知的坑类型3Regression Case历史问题不复现- 定义曾经出过问题的真实case- 示例- 上次把测试代码标记为生产Bug的case不能再犯- 上次忽略了并发安全问题的case现在必须识别出来- 验证方式对比历史错误输出确认已修复- 数量持续积累每次线上问题都新增一条回归流程- 修改SKILL → 本地跑Golden Case5分钟- → 全部通过 → 跑Boundary Regression15分钟- → 全部通过 → 提交- → 任何失败 → 分析原因修复后重跑为什么这很重要因为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更准一点四个引擎之间的驱动关系引擎输入输出驱动下一个引擎知识构建日常开发中的实战经验判断框架和蒸馏知识→ 输出成为references的原料信息披露蒸馏后的知识精准的references设计→ 高质量reference让SKILL跑得好架构迭代使用中的反馈更健壮的SKILL结构→ 稳定的架构让迭代更安全自我进化执行数据积累改进建议→ 发现的新知识反哺知识构建这四个引擎形成正循环知识越好 → reference越准 → SKILL跑得越好 → 积累的数据越有价值 → 发现的改进方向越精准 → 知识进一步提升。六、结语AI时代的长期主义回到开头的问题这些东西能跑多久答案取决于你把自己定位成什么角色。如果你是SKILL使用者——拿别人写好的SKILL跑用别人沉淀的knowledge那你的价值会随着AI工具的普及而递减。因为谁都能跑。如果你是知识工程师——持续蒸馏业务认知、精细化设计信息披露、工程化维护SKILL架构、建立自我迭代闭环那你的价值会随着时间的推移而递增。因为这些能力是用出来的不是学出来的。两种角色的价值曲线SKILL使用者- 短期能用AI出活效率提升明显- 中期AI工具普及大家都能出活差距缩小- 长期差异化消失回到同一起跑线知识工程师- 短期前期投入大搭建框架、沉淀知识、设计测试- 中期复利效应启动SKILL越来越准效率持续拉开差距- 长期判断框架 迭代闭环形成壁垒别人很难追上30天进阶到这里我们覆盖了一条完整的路径Week 1学会写SKILL——让AI按你的规则输出Week 2MCP Agent——让AI连接世界、多步协作Week 3Harness 安全——让AI在约束中可靠运行Week 4源码机制——理解AI决策的底层逻辑Day 26-30实战进阶——不可替代性、知识复利、防幻觉、团队协同、生产执行加餐篇与AI共同进化——从用AI到与AI共建长期价值这30天教给你的不是怎么用Claude Code是怎么在AI时代构建可持续的技术竞争力。工具会迭代模型会升级但有一件事不会变能把AI的能力稳定地转化为业务价值的人永远稀缺。与AI共同进化不是口号是一种工作方式。从今天开始每一次SKILL执行、每一条用户反馈、每一个踩过的坑都是你和AI共同积累的资产。让复利开始滚动。