1. 新手装 Skill 之前先把三层框架想明白刚接触 Codex 的人十个里有八个会卡在同一个问题上Skill 到底该装哪些。打开社区一看有人推荐装几十个有人说什么都别装先用原生还有人甩出一长串名字你连干什么的都不知道。我一开始也是这样装了一堆结果真正每天用到的就那么三五个剩下的全在吃灰有的甚至因为触发条件写得太宽老是误触发反而拖慢了正常干活。后来我复盘了一下发现问题的根源不在于“哪个 Skill 好”而在于没有先想清楚自己处在什么阶段、要解决什么问题。Skill 这个东西本质上是给 Codex 加“外挂能力”的你缺什么补什么而不是别人有什么你就装什么。所以我把它分成三层来挑基础层、提效层、业务层。这三层不是按重要性排的而是按你的使用深度递进的。基础层解决“能不能用”的问题提效层解决“用得顺不顺”的问题业务层解决“能不能干我的活”的问题。这篇文章就是把我自己从零开始装 Skill 的完整思路拆开讲包括每一层该装什么、为什么装、怎么配、踩过哪些坑。如果你刚上手 Codex或者装了一堆但感觉没章法可以对着这个框架重新理一遍。如果你已经用了一段时间也可以看看业务层那部分大概率能找到几个之前没注意到的方向。核心原则就一句话Skill 不是越多越好而是每一层先装一两个跑通确认真的用得上再往下加。贪多必翻车。2. 基础层先让 Codex 能正常干活2.1 基础层到底解决什么问题基础层要解决的核心问题是让 Codex 在你的环境里能跑起来、能理解你的项目、能执行最基本的操作。听起来很基础对吧但我见过太多人跳过这一步直接去装各种花哨的业务 Skill结果连项目结构都没让 Codex 读明白生成的东西驴唇不对马嘴。基础层的 Skill 通常不涉及具体业务逻辑它们更像是“通用能力补丁”。比如文件读写、命令执行、代码搜索、环境感知这些。Codex 本身有内置能力但内置能力往往是通用型的面对具体语言、具体框架、具体项目结构时就需要基础层 Skill 来补位。我自己的做法是新环境先只装基础层跑一周确认日常操作没有卡点再考虑往上加。这一周里你会很清楚自己缺什么而不是凭想象装一堆。2.2 语言基础类 Skill 怎么选语言基础类的 Skill 是最先该考虑的。你主要用什么语言写代码就装对应的基础 Skill。比如你写 Python那就装 Python 基础语法相关的 Skill写 Java就装 Java 基础相关的前端方向就装 JavaScript 基础、HTML 基础这类。但这里有个坑不要按语言数量来装要按你实际写代码的频率来装。我见过有人把 C 语言基础、Python 基础、JavaScript 基础、Java 基础全装了结果每个都只用了一两次。正确的做法是你最近三个月主要写什么就装什么。其他的等真正用到再说。具体到选择标准我看三个点是否覆盖语法层面的常见问题比如 Python 基础 Skill 能不能处理列表推导、装饰器、类型注解这些高频写法是否能结合项目上下文好的基础 Skill 不是干巴巴讲语法而是能读你项目里的代码然后给出符合项目风格的补全触发条件是否合理有些基础 Skill 触发太宽你写任何代码它都跳出来反而干扰。理想的是你明确需要语法帮助时才触发以 Python 基础为例我装的那个 Skill 主要帮我做三件事补全常用标准库写法、检查语法层面的低级错误、在我不确定某个写法是否 Pythonic 时给建议。它不负责业务逻辑也不负责架构设计边界很清晰。2.3 环境与工具类 Skill 的配置要点环境类 Skill 是另一个基础层重点。这类 Skill 让 Codex 能感知你的开发环境比如当前目录结构、依赖版本、运行环境等。没有这类 SkillCodex 就是在“盲写”生成的东西可能跟你环境完全不兼容。我一般会配这几个方向的环境 Skill项目结构感知让 Codex 能读取项目目录树理解模块划分依赖管理感知能读取依赖文件知道项目用了哪些库、什么版本运行环境感知知道当前是什么系统、什么运行时版本配置这类 Skill 的时候权限范围要控制好。有些环境 Skill 默认能读取整个文件系统这没必要而且有风险。我通常会把读取范围限制在当前项目目录内既够用又安全。实操心得环境类 Skill 装完后一定要做一次验证。随便让它读一个项目文件看它能不能正确理解路径和内容。我遇到过 Skill 装了但路径映射没配好Codex 读到的全是空内容生成的东西完全不对排查了半天才发现是配置问题。2.4 基础层装完后的验证清单基础层装完别急着往上加。先跑一遍验证清单验证项怎么验通过标准文件读取让 Codex 读一个项目文件并总结能正确读出内容并理解命令执行让 Codex 执行一个简单命令能执行并返回正确结果语法补全写一段有语法缺漏的代码能识别并给出合理补全环境感知问它当前项目用了什么依赖能准确回答触发边界正常写业务代码基础 Skill 不胡乱触发这五项都过了基础层就算稳了。有一项没过先排查那一项别往下走。基础不牢后面全是坑。3. 提效层把重复劳动交给 Skill3.1 提效层的判断标准什么事值得做成 Skill基础层跑通之后你会开始觉得“有些操作每次都要重复做很烦”。这时候就该考虑提效层了。但不是什么重复劳动都值得做成 Skill我的判断标准是三条频率高一周至少用三次以上才值得投入时间配 Skill步骤固定每次做的流程基本一样不需要太多临场判断容易出错手工做容易漏步骤或写错交给 Skill 更稳三条都满足才值得做成提效 Skill。只满足一条两条的先忍忍或者用简单的脚本代替不一定非要上 Skill。我见过有人把只用过两次的操作也做成 Skill结果配了半天用了一次就再也没用过。时间全浪费在配置上了。提效的前提是“真的有量”量不够提效就是伪命题。3.2 代码生成与重构类提效 Skill这类 Skill 是我用得最多的。核心场景是把重复性的代码生成和重构工作自动化。比如我经常需要根据一个数据模型生成对应的 CRUD 代码。以前是手工写一个模型写一遍十个模型写十遍又慢又容易写错。后来配了一个提效 Skill输入模型定义直接生成符合项目规范的 CRUD 代码包括参数校验、异常处理、日志埋点这些固定套路。生成完我再检查一遍比手工写快了好几倍。重构类也是类似。比如项目里有一批老代码需要统一改风格手工改容易漏。配一个重构 Skill定义好改造规则批量跑一遍改完再抽查。这里的关键是规则要写清楚不能含糊。规则越明确Skill 执行越稳。注意事项代码生成类 Skill 生成的东西一定要过一遍。我遇到过 Skill 生成的代码逻辑没问题但用了项目里已经废弃的 API直接跑会报错。所以生成之后依赖检查这一步不能省。3.3 文档与注释类提效 Skill写文档和注释是典型的“知道该做但不想做”的事。提效层里配一个文档类 Skill能省不少事。我的做法是配两个方向的文档 Skill一个是代码注释生成针对函数和类根据代码逻辑生成符合项目注释规范的文档字符串另一个是变更记录生成根据代码 diff 自动生成变更说明。注释类 Skill 的关键是注释规范要跟项目一致。不同项目注释风格可能不一样有的用 Google 风格有的用 NumPy 风格。配 Skill 的时候要把规范写进去不然生成的注释风格不统一反而添乱。变更记录类 Skill 我一般配合版本管理用。每次提交前跑一下自动生成这次改了什么、影响哪些模块。比手工写准确也不容易漏。3.4 测试与调试类提效 Skill测试类提效 Skill 主要解决两个问题生成测试用例和辅助定位问题。生成测试用例这块我配的 Skill 能根据函数签名和逻辑生成覆盖主要分支的测试用例。它不追求 100% 覆盖率而是先把核心路径覆盖了边界情况我再补充。这样比从零写测试快很多。调试辅助这块配一个能读日志、能分析报错栈的 Skill。出问题的时候把报错信息丢给它它能快速定位到可能出问题的代码位置并给出排查建议。这个在排查一些不熟悉的模块时特别有用。提效方向典型 Skill 能力使用频率我的推荐优先级代码生成根据模型生成 CRUD高第一优先代码重构批量改代码风格中第二优先注释生成自动生成文档字符串中第二优先变更记录根据 diff 生成说明中第三优先测试生成生成测试用例中第二优先调试辅助分析报错定位问题高第一优先3.5 提效层 Skill 的触发条件怎么设提效层 Skill 最容易出的问题是触发条件设得太宽。比如你配了一个代码生成 Skill结果你正常写代码它也不停跳出来建议生成很烦。我的经验是提效类 Skill 尽量用显式触发不要用隐式触发。显式触发就是你明确调用它才启动隐式触发是它自己判断该启动了。隐式触发听起来智能实际上很容易误判。显式触发虽然多一步操作但可控性强得多。具体怎么设看 Skill 支持的触发方式。有的支持命令触发有的支持关键词触发。我一般用命令触发比如输入一个特定前缀才启动对应 Skill。这样日常写代码完全不受干扰需要的时候再叫它。4. 业务层让 Codex 真正懂你的活4.1 业务层 Skill 的核心价值基础层让 Codex 能用提效层让 Codex 好用业务层让 Codex真正懂你在干什么。这是三层里最个性化的一层因为每个人的业务都不一样。业务层 Skill 的核心价值是把业务领域的知识、流程、规范注入到 Codex 里让它生成的东西符合业务实际而不是泛泛的通用代码。比如你做电商业务层 Skill 应该懂订单、库存、支付这些概念你做企业系统业务层 Skill 应该懂采购、销售、库存这些流程。没有业务层 SkillCodex 就是个通用助手什么都能聊但什么都不精。有了业务层 Skill它才能在你具体的工作场景里给出真正有用的建议。4.2 业务流程类 Skill 怎么配业务流程类 Skill 是业务层的基础。它的作用是让 Codex 理解你所在领域的业务流程比如一个订单从创建到完成要经过哪些状态、一个采购流程涉及哪些角色和审批节点。配这类 Skill 的关键是把流程图画清楚。不是让 Codex 自己猜流程而是你把流程明确写进去。我一般会整理一份业务流程说明包括核心业务对象有哪些每个对象的生命周期状态状态之间的流转条件每个环节涉及的角色和操作这份说明写清楚之后配成 SkillCodex 在生成业务代码时就能自动遵循这些流程不会出现状态流转不对、角色权限搞错这类问题。实操心得业务流程说明不用一次写全先写核心流程用起来之后发现缺什么再补。我一开始想写全结果写了三天还没写完后来改成先写订单主流程用了一周发现缺退款流程再补上。迭代着来比一次性写完更实际。4.3 领域知识类 Skill 的积累方法领域知识类 Skill 比业务流程更细它关注的是具体业务概念和规则。比如电商里的优惠券规则、库存扣减规则、价格计算规则企业系统里的科目映射、税率计算、审批规则。这类 Skill 的积累方法是遇到一个规则就记一个慢慢攒。不要想着一次性把领域知识全整理完那不可能。我的做法是建一个领域知识库每次遇到 Codex 生成的东西不符合业务规则就把正确规则补进去。用着用着这个知识库就越来越全Codex 也越来越懂我的业务。这里有个技巧规则要写成可执行的判断形式不要写成描述性文字。比如不要写“优惠券有使用门槛”而要写“优惠券使用条件订单金额 门槛金额 且 未过期 且 未使用”。前者 Codex 理解起来模糊后者它能直接用来做判断。4.4 业务层 Skill 与基础/提效层的配合业务层不是孤立的它要跟基础层、提效层配合。配合的逻辑是基础层提供能力提效层提供效率业务层提供方向。举个例子你要生成一个订单处理函数。基础层让 Codex 能读项目、能写代码提效层的代码生成 Skill 负责按模板生成函数框架业务层的流程 Skill 负责确保函数里的状态流转符合业务规则领域知识 Skill 负责确保优惠券计算、库存扣减这些逻辑正确。三层各司其职缺一层都不行。所以装 Skill 的顺序也应该是基础层先跑通再提效层最后业务层。跳过基础层直接上业务层就像没打地基就盖楼看着快实际上不稳。4.5 业务层 Skill 的维护与迭代业务层 Skill 不是配一次就完事的它需要持续维护。业务在变规则在变Skill 也要跟着变。我的维护节奏是每月过一遍业务层 Skill看有没有过时的规则。比如某个审批流程改了对应的 Skill 就要更新。某个业务规则废弃了对应的知识条目就要删掉。不维护的话Skill 里的规则跟实际业务脱节生成的东西反而会误导你。另外业务层 Skill 建议做版本管理。每次修改记一下改了什么、为什么改。这样出问题的时候能快速回滚也能看出业务规则的演变过程。5. 三层 Skill 的安装顺序与避坑指南5.1 推荐的安装节奏三层 Skill 不要一次全装按节奏来第一周只装基础层跑通验证清单第二到三周加提效层先装代码生成和调试辅助这两个高频的第四周起开始攒业务层从核心业务流程开始之后持续迭代缺什么补什么这个节奏的好处是每一步都踩实了再走下一步。我见过有人一天装完三层结果出了问题根本不知道是哪层引起的排查成本极高。5.2 常见问题速查问题现象可能原因排查方向Skill 装了没反应触发条件没配好检查触发方式改显式触发Skill 频繁误触发触发条件太宽收窄触发范围加限定条件生成内容不符合项目规范基础层环境感知没配好检查项目结构和依赖读取生成内容不符合业务规则业务层知识缺失补充对应业务规则到 SkillSkill 之间冲突多个 Skill 触发条件重叠梳理触发边界错开触发条件性能变慢装的 Skill 太多精简只留高频使用的5.3 我踩过的几个坑坑一贪多。一开始装了二十多个 Skill结果互相干扰Codex 响应变慢生成质量反而下降。后来精简到八个每个都跑顺了效率反而高。坑二业务规则写太模糊。早期业务层 Skill 里写“按业务规则处理”Codex 根本不知道什么规则。后来改成具体判断条件才真正起作用。坑三不验证就往下走。基础层没跑通就装提效层结果提效 Skill 生成的东西因为基础环境没配好全是错的。返工成本很高。坑四不维护。业务层 Skill 配完就不管了三个月后业务规则变了Skill 还在用老规则生成的东西全要手工改。后来养成每月过一遍的习惯才稳定下来。5.4 给新手的最终建议如果你刚开始我的建议就三条先装基础层跑一周再说。别急着往上加基础不牢后面全是坑。提效层只装高频的。一周用不到三次的先别装。业务层慢慢攒。从核心流程开始遇到问题就补别想一次写完。Skill 这个东西装得对比装得多重要得多。三层框架帮你理清该装什么、什么时候装、怎么装。按这个框架走能少走很多弯路。最后分享一个小技巧每次装新 Skill 之前先问自己“这个 Skill 解决我哪个具体问题”。答不上来的先别装。答得上来的装完记得验证。这个习惯帮我省了很多无效配置的时间。
Codex Skill 三层框架：基础层、提效层、业务层安装指南
1. 新手装 Skill 之前先把三层框架想明白刚接触 Codex 的人十个里有八个会卡在同一个问题上Skill 到底该装哪些。打开社区一看有人推荐装几十个有人说什么都别装先用原生还有人甩出一长串名字你连干什么的都不知道。我一开始也是这样装了一堆结果真正每天用到的就那么三五个剩下的全在吃灰有的甚至因为触发条件写得太宽老是误触发反而拖慢了正常干活。后来我复盘了一下发现问题的根源不在于“哪个 Skill 好”而在于没有先想清楚自己处在什么阶段、要解决什么问题。Skill 这个东西本质上是给 Codex 加“外挂能力”的你缺什么补什么而不是别人有什么你就装什么。所以我把它分成三层来挑基础层、提效层、业务层。这三层不是按重要性排的而是按你的使用深度递进的。基础层解决“能不能用”的问题提效层解决“用得顺不顺”的问题业务层解决“能不能干我的活”的问题。这篇文章就是把我自己从零开始装 Skill 的完整思路拆开讲包括每一层该装什么、为什么装、怎么配、踩过哪些坑。如果你刚上手 Codex或者装了一堆但感觉没章法可以对着这个框架重新理一遍。如果你已经用了一段时间也可以看看业务层那部分大概率能找到几个之前没注意到的方向。核心原则就一句话Skill 不是越多越好而是每一层先装一两个跑通确认真的用得上再往下加。贪多必翻车。2. 基础层先让 Codex 能正常干活2.1 基础层到底解决什么问题基础层要解决的核心问题是让 Codex 在你的环境里能跑起来、能理解你的项目、能执行最基本的操作。听起来很基础对吧但我见过太多人跳过这一步直接去装各种花哨的业务 Skill结果连项目结构都没让 Codex 读明白生成的东西驴唇不对马嘴。基础层的 Skill 通常不涉及具体业务逻辑它们更像是“通用能力补丁”。比如文件读写、命令执行、代码搜索、环境感知这些。Codex 本身有内置能力但内置能力往往是通用型的面对具体语言、具体框架、具体项目结构时就需要基础层 Skill 来补位。我自己的做法是新环境先只装基础层跑一周确认日常操作没有卡点再考虑往上加。这一周里你会很清楚自己缺什么而不是凭想象装一堆。2.2 语言基础类 Skill 怎么选语言基础类的 Skill 是最先该考虑的。你主要用什么语言写代码就装对应的基础 Skill。比如你写 Python那就装 Python 基础语法相关的 Skill写 Java就装 Java 基础相关的前端方向就装 JavaScript 基础、HTML 基础这类。但这里有个坑不要按语言数量来装要按你实际写代码的频率来装。我见过有人把 C 语言基础、Python 基础、JavaScript 基础、Java 基础全装了结果每个都只用了一两次。正确的做法是你最近三个月主要写什么就装什么。其他的等真正用到再说。具体到选择标准我看三个点是否覆盖语法层面的常见问题比如 Python 基础 Skill 能不能处理列表推导、装饰器、类型注解这些高频写法是否能结合项目上下文好的基础 Skill 不是干巴巴讲语法而是能读你项目里的代码然后给出符合项目风格的补全触发条件是否合理有些基础 Skill 触发太宽你写任何代码它都跳出来反而干扰。理想的是你明确需要语法帮助时才触发以 Python 基础为例我装的那个 Skill 主要帮我做三件事补全常用标准库写法、检查语法层面的低级错误、在我不确定某个写法是否 Pythonic 时给建议。它不负责业务逻辑也不负责架构设计边界很清晰。2.3 环境与工具类 Skill 的配置要点环境类 Skill 是另一个基础层重点。这类 Skill 让 Codex 能感知你的开发环境比如当前目录结构、依赖版本、运行环境等。没有这类 SkillCodex 就是在“盲写”生成的东西可能跟你环境完全不兼容。我一般会配这几个方向的环境 Skill项目结构感知让 Codex 能读取项目目录树理解模块划分依赖管理感知能读取依赖文件知道项目用了哪些库、什么版本运行环境感知知道当前是什么系统、什么运行时版本配置这类 Skill 的时候权限范围要控制好。有些环境 Skill 默认能读取整个文件系统这没必要而且有风险。我通常会把读取范围限制在当前项目目录内既够用又安全。实操心得环境类 Skill 装完后一定要做一次验证。随便让它读一个项目文件看它能不能正确理解路径和内容。我遇到过 Skill 装了但路径映射没配好Codex 读到的全是空内容生成的东西完全不对排查了半天才发现是配置问题。2.4 基础层装完后的验证清单基础层装完别急着往上加。先跑一遍验证清单验证项怎么验通过标准文件读取让 Codex 读一个项目文件并总结能正确读出内容并理解命令执行让 Codex 执行一个简单命令能执行并返回正确结果语法补全写一段有语法缺漏的代码能识别并给出合理补全环境感知问它当前项目用了什么依赖能准确回答触发边界正常写业务代码基础 Skill 不胡乱触发这五项都过了基础层就算稳了。有一项没过先排查那一项别往下走。基础不牢后面全是坑。3. 提效层把重复劳动交给 Skill3.1 提效层的判断标准什么事值得做成 Skill基础层跑通之后你会开始觉得“有些操作每次都要重复做很烦”。这时候就该考虑提效层了。但不是什么重复劳动都值得做成 Skill我的判断标准是三条频率高一周至少用三次以上才值得投入时间配 Skill步骤固定每次做的流程基本一样不需要太多临场判断容易出错手工做容易漏步骤或写错交给 Skill 更稳三条都满足才值得做成提效 Skill。只满足一条两条的先忍忍或者用简单的脚本代替不一定非要上 Skill。我见过有人把只用过两次的操作也做成 Skill结果配了半天用了一次就再也没用过。时间全浪费在配置上了。提效的前提是“真的有量”量不够提效就是伪命题。3.2 代码生成与重构类提效 Skill这类 Skill 是我用得最多的。核心场景是把重复性的代码生成和重构工作自动化。比如我经常需要根据一个数据模型生成对应的 CRUD 代码。以前是手工写一个模型写一遍十个模型写十遍又慢又容易写错。后来配了一个提效 Skill输入模型定义直接生成符合项目规范的 CRUD 代码包括参数校验、异常处理、日志埋点这些固定套路。生成完我再检查一遍比手工写快了好几倍。重构类也是类似。比如项目里有一批老代码需要统一改风格手工改容易漏。配一个重构 Skill定义好改造规则批量跑一遍改完再抽查。这里的关键是规则要写清楚不能含糊。规则越明确Skill 执行越稳。注意事项代码生成类 Skill 生成的东西一定要过一遍。我遇到过 Skill 生成的代码逻辑没问题但用了项目里已经废弃的 API直接跑会报错。所以生成之后依赖检查这一步不能省。3.3 文档与注释类提效 Skill写文档和注释是典型的“知道该做但不想做”的事。提效层里配一个文档类 Skill能省不少事。我的做法是配两个方向的文档 Skill一个是代码注释生成针对函数和类根据代码逻辑生成符合项目注释规范的文档字符串另一个是变更记录生成根据代码 diff 自动生成变更说明。注释类 Skill 的关键是注释规范要跟项目一致。不同项目注释风格可能不一样有的用 Google 风格有的用 NumPy 风格。配 Skill 的时候要把规范写进去不然生成的注释风格不统一反而添乱。变更记录类 Skill 我一般配合版本管理用。每次提交前跑一下自动生成这次改了什么、影响哪些模块。比手工写准确也不容易漏。3.4 测试与调试类提效 Skill测试类提效 Skill 主要解决两个问题生成测试用例和辅助定位问题。生成测试用例这块我配的 Skill 能根据函数签名和逻辑生成覆盖主要分支的测试用例。它不追求 100% 覆盖率而是先把核心路径覆盖了边界情况我再补充。这样比从零写测试快很多。调试辅助这块配一个能读日志、能分析报错栈的 Skill。出问题的时候把报错信息丢给它它能快速定位到可能出问题的代码位置并给出排查建议。这个在排查一些不熟悉的模块时特别有用。提效方向典型 Skill 能力使用频率我的推荐优先级代码生成根据模型生成 CRUD高第一优先代码重构批量改代码风格中第二优先注释生成自动生成文档字符串中第二优先变更记录根据 diff 生成说明中第三优先测试生成生成测试用例中第二优先调试辅助分析报错定位问题高第一优先3.5 提效层 Skill 的触发条件怎么设提效层 Skill 最容易出的问题是触发条件设得太宽。比如你配了一个代码生成 Skill结果你正常写代码它也不停跳出来建议生成很烦。我的经验是提效类 Skill 尽量用显式触发不要用隐式触发。显式触发就是你明确调用它才启动隐式触发是它自己判断该启动了。隐式触发听起来智能实际上很容易误判。显式触发虽然多一步操作但可控性强得多。具体怎么设看 Skill 支持的触发方式。有的支持命令触发有的支持关键词触发。我一般用命令触发比如输入一个特定前缀才启动对应 Skill。这样日常写代码完全不受干扰需要的时候再叫它。4. 业务层让 Codex 真正懂你的活4.1 业务层 Skill 的核心价值基础层让 Codex 能用提效层让 Codex 好用业务层让 Codex真正懂你在干什么。这是三层里最个性化的一层因为每个人的业务都不一样。业务层 Skill 的核心价值是把业务领域的知识、流程、规范注入到 Codex 里让它生成的东西符合业务实际而不是泛泛的通用代码。比如你做电商业务层 Skill 应该懂订单、库存、支付这些概念你做企业系统业务层 Skill 应该懂采购、销售、库存这些流程。没有业务层 SkillCodex 就是个通用助手什么都能聊但什么都不精。有了业务层 Skill它才能在你具体的工作场景里给出真正有用的建议。4.2 业务流程类 Skill 怎么配业务流程类 Skill 是业务层的基础。它的作用是让 Codex 理解你所在领域的业务流程比如一个订单从创建到完成要经过哪些状态、一个采购流程涉及哪些角色和审批节点。配这类 Skill 的关键是把流程图画清楚。不是让 Codex 自己猜流程而是你把流程明确写进去。我一般会整理一份业务流程说明包括核心业务对象有哪些每个对象的生命周期状态状态之间的流转条件每个环节涉及的角色和操作这份说明写清楚之后配成 SkillCodex 在生成业务代码时就能自动遵循这些流程不会出现状态流转不对、角色权限搞错这类问题。实操心得业务流程说明不用一次写全先写核心流程用起来之后发现缺什么再补。我一开始想写全结果写了三天还没写完后来改成先写订单主流程用了一周发现缺退款流程再补上。迭代着来比一次性写完更实际。4.3 领域知识类 Skill 的积累方法领域知识类 Skill 比业务流程更细它关注的是具体业务概念和规则。比如电商里的优惠券规则、库存扣减规则、价格计算规则企业系统里的科目映射、税率计算、审批规则。这类 Skill 的积累方法是遇到一个规则就记一个慢慢攒。不要想着一次性把领域知识全整理完那不可能。我的做法是建一个领域知识库每次遇到 Codex 生成的东西不符合业务规则就把正确规则补进去。用着用着这个知识库就越来越全Codex 也越来越懂我的业务。这里有个技巧规则要写成可执行的判断形式不要写成描述性文字。比如不要写“优惠券有使用门槛”而要写“优惠券使用条件订单金额 门槛金额 且 未过期 且 未使用”。前者 Codex 理解起来模糊后者它能直接用来做判断。4.4 业务层 Skill 与基础/提效层的配合业务层不是孤立的它要跟基础层、提效层配合。配合的逻辑是基础层提供能力提效层提供效率业务层提供方向。举个例子你要生成一个订单处理函数。基础层让 Codex 能读项目、能写代码提效层的代码生成 Skill 负责按模板生成函数框架业务层的流程 Skill 负责确保函数里的状态流转符合业务规则领域知识 Skill 负责确保优惠券计算、库存扣减这些逻辑正确。三层各司其职缺一层都不行。所以装 Skill 的顺序也应该是基础层先跑通再提效层最后业务层。跳过基础层直接上业务层就像没打地基就盖楼看着快实际上不稳。4.5 业务层 Skill 的维护与迭代业务层 Skill 不是配一次就完事的它需要持续维护。业务在变规则在变Skill 也要跟着变。我的维护节奏是每月过一遍业务层 Skill看有没有过时的规则。比如某个审批流程改了对应的 Skill 就要更新。某个业务规则废弃了对应的知识条目就要删掉。不维护的话Skill 里的规则跟实际业务脱节生成的东西反而会误导你。另外业务层 Skill 建议做版本管理。每次修改记一下改了什么、为什么改。这样出问题的时候能快速回滚也能看出业务规则的演变过程。5. 三层 Skill 的安装顺序与避坑指南5.1 推荐的安装节奏三层 Skill 不要一次全装按节奏来第一周只装基础层跑通验证清单第二到三周加提效层先装代码生成和调试辅助这两个高频的第四周起开始攒业务层从核心业务流程开始之后持续迭代缺什么补什么这个节奏的好处是每一步都踩实了再走下一步。我见过有人一天装完三层结果出了问题根本不知道是哪层引起的排查成本极高。5.2 常见问题速查问题现象可能原因排查方向Skill 装了没反应触发条件没配好检查触发方式改显式触发Skill 频繁误触发触发条件太宽收窄触发范围加限定条件生成内容不符合项目规范基础层环境感知没配好检查项目结构和依赖读取生成内容不符合业务规则业务层知识缺失补充对应业务规则到 SkillSkill 之间冲突多个 Skill 触发条件重叠梳理触发边界错开触发条件性能变慢装的 Skill 太多精简只留高频使用的5.3 我踩过的几个坑坑一贪多。一开始装了二十多个 Skill结果互相干扰Codex 响应变慢生成质量反而下降。后来精简到八个每个都跑顺了效率反而高。坑二业务规则写太模糊。早期业务层 Skill 里写“按业务规则处理”Codex 根本不知道什么规则。后来改成具体判断条件才真正起作用。坑三不验证就往下走。基础层没跑通就装提效层结果提效 Skill 生成的东西因为基础环境没配好全是错的。返工成本很高。坑四不维护。业务层 Skill 配完就不管了三个月后业务规则变了Skill 还在用老规则生成的东西全要手工改。后来养成每月过一遍的习惯才稳定下来。5.4 给新手的最终建议如果你刚开始我的建议就三条先装基础层跑一周再说。别急着往上加基础不牢后面全是坑。提效层只装高频的。一周用不到三次的先别装。业务层慢慢攒。从核心流程开始遇到问题就补别想一次写完。Skill 这个东西装得对比装得多重要得多。三层框架帮你理清该装什么、什么时候装、怎么装。按这个框架走能少走很多弯路。最后分享一个小技巧每次装新 Skill 之前先问自己“这个 Skill 解决我哪个具体问题”。答不上来的先别装。答得上来的装完记得验证。这个习惯帮我省了很多无效配置的时间。
