企业官网建设流程全解析

如果你同时用 Codex 和 Claude Code 跑过真实项目，八成会跟我有同样的感受：同一个任务，有时候一遍过，有时候来来回回改上十几轮还是错的。一开始我也以为是模型脑子不够用，直到我把大量时间花在“帮 Agent 擦屁股”上，才反应过来——问题不在推理能力，而在我们交给它的工作流实在太粗糙了。

过去大半年，我一直在折腾一套叫 AI-Infra-Auto-Driven-SKILLS 的技能库框架，目的很直接：把平时散落在文档里、聊天记录里、代码注释里的“项目经验”，变成 Agent 可以自主读取、按条件触发、逐步执行的显式技能文件。目前迭代到了 v0.1.5，配合 Codex 和 Claude Code 的上下文机制，在跨文件重构、测试补全、回归检查这几类任务上，效果比裸用模型稳定得多。

这篇文章不打算讲什么宏大理论，就聊聊这套推理框架工作流到底长什么样、我在 v0.1.5 这轮里改了什么、落地时会踩到哪些坑。

1. 先说清楚：这套技能框架解决的到底是什么问题

1.1 两个 Agent 用久了之后最让人头疼的几种“犯蠢”

先说几个我反复遇到的场景，你看完肯定有共鸣。

第一个场景是“重复造轮子”。项目里明明已经有一个写好的工具函数，负责统一处理时间格式转换。结果某次我让 Agent 在一个新模块里加日志，它非常自然地又写了一个几乎一模一样的函数，只是参数名换了。问它为什么不用现成的，它的回答是“未在上下文中检索到该项目已有该工具函数”。

第二个场景是“改一处崩三处”。我给 Claude Code 一个重构任务，要求把某个核心接口从同步改为异步。它一口气改了十几个文件，然后信心满满地告诉我完成了。结果编译一跑，五个调用方还在用旧签名。问题不是它不会改，而是它改的时候没有系统性地把“所有受影响调用方”纳入检查范围，完全靠上下文里残留的信息猜。

第三个场景是“不遵守项目内既定约定”。某个仓库里有一套严格的错误处理规范，要求所有外部调用必须用特定的包装类型返回错误。Agent 写新代码的时候总是按自己习惯来，写得倒很整齐，但跟项目风格完全不一致。事后我一条条跟它讲规范、让它重写，返工成本高得离谱。

这三个场景，表面看是“模型不够聪明”，但细究下来其实是一类问题：模型对项目的理解是碎片化的、短期的，它没有“项目经验”这种长程记忆。你指望它每次开对话都从代码里自动归纳出全部约定，不现实。

1.2 本质原因：模型没有“项目经验”，上下文窗口也没有记忆

很多人对 Agent 有个误解，以为它能像老员工一样“心里有数”。实际上，每次新对话，模型面对的都是一个什么都不懂的实习生。它确实读过整个代码库——准确地说是你喂给它的那部分——但它不会自动提炼出“这个项目的接口变更流程是什么”“约定的目录结构为什么这样设计”“哪些代码是不能碰的历史包袱”。

就算你把整个项目都放进上下文，也没用。上下文窗口是有极限的，塞满之后，模型反而会丢失对局部细节的注意力。而且项目约定这种东西，往往散落在不同地方：README 里一段、某个模块顶部注释里一段、某个历史 commit message 里一段。模型不会主动把这些信息拼成一个完整的规则系统。

所以问题的真正解法，不是给模型换更大的上下文，而是给它一个“经验查询机制”：让它知道在什么时候、去哪里、读取哪一条经验规则，然后按规则执行。这就是技能层存在的意义。

1.3 为什么叫 Auto-Driven 而不是手动 Prompt 模板

市面上已经有很多人分享“神仙 Prompt”，把一大段精心设计的指令放在系统提示词里。这种做法也能用，但本质上是被动的：Prompt 只能覆盖你预先想到的场景，一旦任务超出预设，它就失效了。而且提示词写多了，会占掉大量上下文空间，Agent 反而变得迟钝。

Auto-Driven 的思路不一样。技能文件不是一条写死的指令，而是一本“操作手册”。Agent 在接到任务时，先根据任务描述里的信号（比如“重构”“迁移”“替换”“跨文件”），自己去匹配应该调用哪本手册，然后按手册里写的步骤一步步执行。

两者的区别，类比一下就是：手动 Prompt 像你每次都牵着实习生的手告诉他怎么做；Auto-Driven 技能层像是你给实习生一个书架，告诉他“遇到哪类问题就去翻哪本书”，他自己读、自己判断、自己照着做。后者才能真正让 Agent 在复杂项目里跑起来。

我在 v0.1.5 里做的事情，本质上就是把这个“书架”搭得更合理，让 Agent 更快找到正确的书、更少拿错书。

2. 技能层的核心设计：把隐性经验变成显式协议

2.1 一份技能清单该写什么、不写什么

很多人第一次搭技能库容易犯一个毛病：什么都往里塞。我自己 v0.1.0 的时候就写了一大堆技能，从“Go 语言最佳实践”到“数据库索引设计原则”，结果 Agent 每次任务都要扫描一遍，上下文直接爆掉。

后来我总结出一条经验：技能文件只写“在这个项目里该怎么做”，不写“通用知识”。比如“Go 语言里 channel 怎么用”这种内容，模型本来就会，不需要你教；但“本项目的错误处理必须走 errorx.Wrap 统一包装”“迁移数据库时必须在 migration 目录下提交双向 SQL”这类项目特有的约定，才是值得写成技能的东西。

技能清单应该包含四类信息：

• 触发场景：什么类型的任务进入这个技能的处理范围。
• 执行步骤：处理此类任务时，先做什么、再做什么、最后验证什么。
• 判定标准：做到什么程度算完成，哪些信号代表当前操作有问题。
• 回退方案：执行失败时，应该从哪里重新开始，或者什么时候该停下来问人。

不写的内容也重要。技能文件里不应该出现具体的业务逻辑实现——那是代码的事，不是技能的职责。也不应该写一次性任务，比如“帮我把这个 bug 修了”，这种用完即弃的东西放技能库里只会增加噪声。

2.2 触发条件与执行入口：让 Agent 自己决定何时调用

技能层最核心的机制是“自主触发”。Agent 需要根据当前任务判断该调用哪个技能，而不是靠用户手动 /skill-name 去敲。

为了让自主触发可靠，每个技能文件的头部都有一段 frontmatter，里面最关键的是 when_to_use 和 when_not_to_use 这两个字段。我在 v0.1.5 里把它们称为“触发评估表”——不光告诉 Agent 什么时候用，还明确告诉它什么时候不要用。

拿跨文件重构这个技能举例，它的触发评估表长这样：

--- name: cross-file-refactor description: 跨文件重构成熟度检查。当需要修改多个文件的结构、迁移接口或替换调用链时使用。 when_to_use: - 任务描述出现“重构”“迁移”“替换”“大范围改动” - 涉及接口签名调整、文件结构调整、调用方批量更新 - 修改一个模块后，预计会影响超过3个其他文件 when_not_to_use: - 仅修改单个文件内的局部逻辑 - 纯新增功能，不涉及现有接口变动 - 只改文档和注释 priority: high ---

这个设计的关键在于“不适用信号”。一开始我只有 when_to_use，结果 Agent 会把所有沾点边的任务都套到这个技能上，反而增加了不必要的步骤。加了 when_not_to_use 之后，误触发率明显下降。

另外，description 字段要写成“搜索引擎摘要”的风格。Agent 在匹配技能时，本质上是拿任务描述跟技能描述做语义匹配，所以描述里要包含任务场景关键词，而不是一段空泛的话。

2.3 上下文激活区：控制 Token 消耗的设计

技能文件不能一股脑全读进上下文，必须分级加载。否则技能库一壮大，Agent 的开场思考里就全是技能内容，正事还没干，上下文先废了一半。

我的方案是做一个三层的上下文激活区：

第一层是索引区，通常放在项目根目录的 SKILLS.md 里。这个文件非常短，只列每个技能的名称、一句话描述和文件路径。Agent 每次对话开始时读一遍索引，知道“有这么些技能可用”。

第二层是常驻区，也就是全局规则文件（Claude Code 里是 CLAUDE.md，Codex 里是 AGENTS.md）。这里只写高层原则，比如“进行任何跨文件修改前，必须查找并更新所有调用方”“提交前必须跑完整测试”。这些原则不隶属于某个具体技能，是贯穿所有任务的底线。

第三层是按需加载区，真正的技能文件。只有当 Agent 根据索引判断“当前任务属于这个技能的触发范围”时，才会主动去读取完整的技能文件。这个读取是实时的、任务相关的，不会长期占用上下文。

这套三层设计很关键。你如果直接把二十个技能文件都塞给 Agent，它就会被大量无关步骤干扰；但如果没有索引层，Agent 又不知道去哪里找技能。索引区让“发现”和“加载”分离，成本可控。

2.4 每个技能的标准结构：让步骤可执行、可验证

技能正文部分我统一用“执行协议 + 验证清单 + 回退信号”三段式结构。以跨文件重构技能为例，它的简化版本是这样的：

# 执行协议 1. 先构建当前调用关系图，列出所有受影响的文件。基于代码检索逐文件确认，不要凭记忆猜。 2. 从受影响最小的文件开始改，每改完一个文件立即跑编译/测试，不允许一次性改完再验证。 3. 接口变更时，所有调用方必须同步更新，禁止留下兼容层或过期注释。 4. 全部改动完成后，输出变更摘要：涉及文件清单、每个文件的改动原因、最终验证结果。 # 验证清单 - [ ] 编译是否通过？ - [ ] 相关测试是否全部通过？ - [ ] 是否还有调用方引用旧接口？ - [ ] 是否还有过期注释或无用的中间代码？ # 回退信号 - 如果调用关系图无法在有限步骤内构建清楚，停止并询问用户。 - 如果编译错误超过5个，回退最近一次改动，重新开始，不要继续硬修。 - 如果新代码与项目既有风格明显不一致，主动对比相邻模块写法再继续。

这套结构的关键在于“可验证”。技能不只是一堆建议，而是每一步都有明确的输出和检查点。Agent 执行到某一步如果卡住，回退信号会告诉它该止损还是换策略。

我当时设计这个三段式的时候，参考了一个很朴素的直觉：如果我自己手动做这个任务，我会怎么控制节奏？答案是“分步走、每步验证、错了及时回头”。技能文件就是把这种节奏显式化，让模型照着做。

3. 在 Codex 和 Claude Code 里落地时的具体差异

3.1 Claude Code：CLAUDE.md 的全局规则与技能分包

Claude Code 对技能库的接入方式相对自然。项目根目录的 CLAUDE.md 是它的常驻记忆文件，每次会话都会读取。我在这里放的是前面说的“常驻区”：几条全局原则 + 技能索引的引用说明。

具体写法上，我利用的是 Claude Code 对文件路径的自动感知能力。在 CLAUDE.md 里我会写上：

# 全局规则 - 任何跨文件修改前，必须先在 SKILLS.md 中检索对应技能，并完整读取技能文件后执行。 - 执行技能时，按技能内“执行协议”的步骤逐一进行，每步完成后检查“验证清单”。 - 当任务超出所有技能覆盖范围时，按通用工程原则处理，并在输出中标注“此处无技能覆盖，按通用逻辑执行”。

关键一点是让 Agent“主动去读技能文件”，而不是把技能内容抄进 CLAUDE.md。CLAUDE.md 的优点是可以无限写，但一旦写长，上下文的常驻开销就上来了。我的经验是：CLAUDE.md 控制在 300 行以内，只写原则和路径，具体操作全部放 skills/ 目录下的独立文件里。

Claude Code 还支持 slash command，比如 /cross-file-refactor 手动触发某个技能。这个我保留作为“人工兜底”，因为有时任务描述比较模糊，Agent 自主匹配可能选错技能。手动触发能强制它读正确的文件，但这个功能我不常用——它本质上又回到了手动 Prompt 模式，多了反而麻烦。

3.2 Codex：AGENTS.md 与显式调用方式

Codex 的语境略有不同。它的常驻文件叫 AGENTS.md，机制跟 CLAUDE.md 类似，但在技能调用的行为习惯上不太一样。我在实际测试中的感受是：Codex 更喜欢“显式指令式”的处理方式，也就是在 AGENTS.md 里写得越直白，它执行得越稳。

例如跨文件重构这个场景，我在 AGENTS.md 里会写：

- 当任务包含“重构”或“迁移”或“替换”关键词时，必须读取 skills/cross-file-refactor.md 并按其步骤执行。 - 读取技能文件后，把技能中的“执行协议”作为任务计划的强制约束，不允许自行简化步骤。 - 每个文件修改完成后，运行一次构建命令，并记录结果。

Codex 对“必须”“不允许”这类强约束词的理解比 Claude Code 更敏感。这可能是两个模型在训练数据上对指令层级理解的差异。我推荐各自工具下尽量贴合工具的口味写规则，不要为了统一格式强行用同一套措辞。

另一个差异是文件路径的写法。Codex 对相对路径的解析有时候会飘，尤其是多目录项目里。保险起见，我在 AGENTS.md 里用的是“路径前缀 + 关键词”的组合描述，比如“仓库根目录下 skills/ 子目录中”。Claude Code 则较少出现这个问题。

3.3 跨工具适配时踩过的兼容性坑

我最初做这套框架的时候，核心目标是“一套技能，双工具通用”。理想很丰满，实际撞了不少墙。

第一个坑是 Markdown 语法的严格程度。Claude Code 对 YAML frontmatter 的解析比较宽松，稍微有点格式瑕疵也能识别；Codex 则更严格，frontmatter 一旦出现无法解析的字段，它可能直接把整个技能文件当作普通文档，不会触发对应机制。后来我统一采用最基础的 YAML 结构，避免使用复杂嵌套、缩进式列表，字段名全部用下划线而非连字符。

第二个坑是两个工具对“优先级”字段的理解不一样。Claude Code 会参考 priority 字段做任务规划，但 Codex 在文件里看到 priority 时基本忽略，它更信 AGENTS.md 里那句“必须读取”的硬指令。所以我在技能文件里保留 priority，但在常驻规则里用强制指令兜底。

第三个坑是技能的“语气”。Claude Code 偏协作，你用“建议”它也会认真执行；Codex 偏任务驱动，你写“建议”它可能真的当建议处理，可做可不做。现在我的技能文件统一用祈使句写操作步骤，把模糊空间尽量压缩。

这三个坑其实没有完美解法，我的处理原则是：技能文件保持中立格式，但每个工具的接入说明里单独调整措辞强度。

4. v0.1.5 这轮迭代：我改了什么，为什么这么改

4.1 v0.1.0 的教训：技能文件膨胀导致上下文爆炸

第一版技能库我写了二十多个技能，从“接口设计原则”到“日志规范”到“数据库迁移”，事无巨细。结果就是：Agent 每次任务开始都要把索引读一遍，然后经常一口气加载三四个技能，上下文窗口被大量步骤描述占据，真正用于代码分析的余量所剩无几。

当时最典型的问题出现在一个模拟项目 X 的前后端联调任务中：Agent 同时加载了“API 设计”“错误处理”“测试规范”三个技能，任务还没开始，思考过程已经写了四五千字，然后开始遗忘前置指令。这让我意识到，技能库不是越全越好，而是越“精准”越好。

4.2 v0.1.3 引入分级技能：L0/L1/L2

从 v0.1.3 开始，我把技能分成三个等级：

L0 技能其实不算“技能”，更像是常驻规则。它们只用几句话描述，不占用大量 token。L1 是主力，写完整执行协议。L2 则是那些你一个月可能用两次但一旦用就需要深度指导的任务。

分级之后，Agent 不会在普通任务里加载 L2 技能，上下文压力大幅缓解。这个改动在纯 token 消耗上感受非常明显：v0.1.0 时代一次中等规模重构的对话平均要烧掉 8 万到 10 万 token，v0.1.3 之后降到 5 万到 6 万。

4.3 v0.1.5 的关键变化：自动触发评估表与回退链路

v0.1.5 这一版最主要的变化有两个，一个是触发评估表，另一个是回退链路。

触发评估表在前面已经展示过了，核心是 when_not_to_use 字段。这个字段的价值不在“锦上添花”，而在于减少 Agent 的无效动作。以前一个技能被误触发后，Agent 会走一遍完整流程，浪费大量步骤和时间；现在它可以在读技能前就完成判断，直接跳过不适用场景，把节省的上下文留给真正的分析。

回退链路则是给技能执行兜底。以前的技能文件只写“怎么做”，没写“做砸了怎么办”。Agent 一旦在某一步卡住，往往会原地打转，不断尝试同一套失败策略。我在 v0.1.5 里给每个技能加了“回退信号”段落，明确定义：哪些情况代表当前方向错了、应该回到哪一步重新开始、或者直接停下来询问用户。

举个例子，跨文件重构技能里的回退信号是：“如果编译错误超过5个，回退最近一次改动，重新开始，不要继续硬修。”这条规则看着普通，但实测中非常管用。Agent 以前会一个错误一个错误地修，修完这个冒出来那个，越陷越深；现在它在错误数量达到阈值后主动回退，反而快速回到正轨。

4.4 版本管理怎么配合 Git 仓库

技能库本身也是一个工程，需要版本管理。我用 git tag 做版本标记，每个 tag 对应一个发布节点。changelog 文件记录了每个版本改了什么、为什么改。比如 v0.1.5 的 changelog 就写了三条：

• 为所有 L1 技能增加 when_not_to_use 触发排除条件；
• 新增“回退信号”字段，明确执行失败时的止损策略；
• 修复 Codex 下 frontmatter 解析兼容性问题（移除嵌套缩进列表）。

跨项目复用的时候，我不直接把技能库整体复制到每个项目，而是把技能库作为一个子模块链接进来，然后在每个项目的 AGENTS.md / CLAUDE.md 里做引用。这样技能库的更新可以一次性推送到所有项目，不需要每个项目手动改。

但注意一点：全局技能库只能放“通用工程经验”，放不了“项目特有约定”。项目特有的错误处理规范、目录结构说明、历史包袱注意事项，必须写在项目自己的常驻文件里。这两者的边界一开始很容易模糊，我的划分标准是：换一个项目这条经验还成立吗？成立，进技能库；不成立，留在项目文件里。

5. 实测：这套工作流在哪些场景真正改变了结果

5.1 多文件重构：从“改一处崩三处”到按协议执行

跨文件重构是我最早写技能、也是收益最明显的场景。v0.1.0 时代几乎每次重构都要我人工盯着改，v0.1.5 版本之后，Agent 的执行路径变得可预测：它会先构建调用关系图、从最小影响文件开始改、每步验证、最后输出变更摘要。

我印象最深的是一次接口迁移任务，涉及 28 个文件。v0.1.5 里的 Agent 先花了几分钟把调用关系梳理清楚，然后按影响范围从小到大逐个文件处理，中间两次因为编译错误触发了回退信号，但回退后都快速修正了方向。最终一次通过率虽然没说 100%，但需要我人工返工的部分明显减少，至少不会出现“改完还漏了三处调用方”这种低级失误。

这套机制的本质是让 Agent 从“凭感觉写代码”变成了“按规程施工”。重构这种事，最怕的不是能力不够，而是节奏失控；技能协议很好地控制了节奏。

5.2 测试补全和回归检查：明显稳了

测试补全这个场景比较有意思。裸用 Agent 时，它的常见问题是：为了覆盖率而编测试，测了很多没用的边缘情况，反而漏了真正的核心路径；或者测完不跑，直接交差。

我在技能库里加了一个“测试补全”的 L1 技能，要求 Agent 做三件事：先定位被测模块的核心业务路径，再按“正常路径—边界条件—异常分支”的顺序补测试，最后必须实际运行测试套件并报告结果。同时规定了一个强制动作：新增测试后必须执行一次全量回归，防止新测试本身破坏了现有测试的假设。

实测下来，这个技能把测试补全任务从“数量量产”变成了“质量产出”，漏测率明显下降。但我也得说句公道话：Agent 写测试用例的“直觉”还不够好，尤其是边界值的选择，经常不是最有代表性的那个。技能可以约束流程，但没法完全替代人的测试设计能力。

5.3 Debug 类任务的现状：仍然需要人工判断

并不是所有任务都在技能化之后变好了。Debug 类任务是我目前觉得收益最小的领域。

技能文件确实可以规定“先复现、再定位、再修复、再验证”这个流程，但问题在于，Bug 的根因往往藏在项目语义里，需要人对业务逻辑的理解。技能可以告诉 Agent 怎么做，但没法告诉它“这个模块的历史包袱是什么”“为什么这里会跟另一个模块产生隐蔽耦合”。

所以在我的技能库里，Debug 类技能是 L2 级别，只在问题特征明确时触发。大部分时间，我宁愿自己先定位到可疑区间，再让 Agent 深入分析，也不让它从头开始盲找。这不是技能框架的失败，而是这个任务类型本身对“项目语境”的依赖太高，单纯靠流程约束解决不了。

5.4 一组客观的对比数据

我在自己的模拟项目 X 上做了一组粗略统计，对比 v0.1.0 和 v0.1.5 的实测表现。说明一下，这不是严格的控制变量实验，样本量也不大，但趋势有参考价值：

一次通过率从 35% 到 70%，主要归功于两件事：触发评估表让 Agent 少做无关动作，回退信号让它错了能及时回头。token 消耗的下降则是分级加载的直接结果。

当然，70% 这个数字离“放心放手”还远得很。碰到复杂跨模块改动，我仍然会全程盯。但对比 v0.1.0 时代“三天两头气得想砸电脑”，现在的工作流已经进入可预测、可干预、可复盘的状态。

6. 如果你也想搭一套，我的建议和避坑清单

6.1 从哪个规模开始尝试最合适

先泼一盆冷水：不要一上来就追求“大而全”。你只需要从当前最痛的一个任务类型开始，比如“跨文件修改老出错”，那就先写这一个技能，加进常驻规则，跑一个星期再说。

我推荐的起步配比是：1 条常驻规则 + 2 到 3 个 L1 技能 + 0 个 L2 技能。先把这套最小闭环跑通，感受技能命中率、上下文开销、返工率的变化，再逐步丰富技能库。一上来就写二十个技能，你根本不知道哪个有用哪个在捣乱。

判断技能是否有效的标准也简单：观察“误用率”。如果技能经常被触发但没带来明显改善，该技能大概率是废话；如果技能很少被触发但触发后总能解决任务，那就是好技能。

6.2 最容易被忽略的三个坑

第一个坑是技能文件的存放位置。Agent 不是会自动扫描整个仓库的，它只会根据常驻文件的指引去读取指定路径。如果你把技能文件放在一个深层级目录、或者名字不够直观，Agent 就会经常找不到。我的经验是：skills/ 目录放仓库根目录下，文件名用描述性短语，比如 cross-file-refactor.md，而不是 01.md、02.md。

第二个坑是触发条件写得太窄或太宽。写窄了，Agent 该用时不用；写宽了，Agent 不该用时乱用。我在 v0.1.5 里用的平衡方法是双向定义：when_to_use 用“任务描述中出现什么词”来锚定，when_not_to_use 用“什么情况下即使出现这些词也不该用”来排除。这个写法值得试。

第三个坑是忽略了技能之间的冲突。比如“跨文件重构”和“代码审查”两个技能，如果同时加载，它们给出的步骤可能有重叠甚至矛盾。我的处理方式是：技能之间通过 priority 字段排序，并在常驻规则里写明“当一个技能的执行步骤与另一个技能重合时，以高优先级技能为准”。

6.3 排查 Agent“不按技能走”的通用方法论

最后聊聊最常见的挫败场景：规则写了，Agent 就是不听。遇到这种情况，我的排查顺序是固定的。

第一步，检查技能文件是否被实际读取。让 Agent 在开头思考里输出“当前读取的技能索引内容”，如果它根本没提到技能文件，问题一定出在路径或触发描述上。

第二步，检查触发条件是否匹配。把实际任务描述和 when_to_use 里的关键词逐一对比，很多时候你以为匹配上了，但语义上并不强相关。

第三步，检查常驻规则和技能文件的约束是否冲突。比如常驻规则里可能有一条“优先使用项目既有工具函数”，而技能文件里写着“按新技术栈封装 API”，这俩放在一起，Agent 自然不知道该听谁的。

第四步，也是最后一步，才是怀疑模型理解能力的问题。以上三步都排除了还不行，那就换一种措辞风格、或者拆成更细的技能再试。

我在 v0.1.5 开发过程中，至少有一半的“Agent 不听话”属于第二步问题——不是 Agent 的问题，是我触发条件写得不清不楚。把这一点想明白之后，心态会好很多。

我自己在这几轮迭代里最大的体会是：主模型的能力给了我们很大的想象空间，但把想象变成稳定产出，靠的是一点点把“经验”磨成显式、可加载、可验证的协议。技能库不是什么玄学手段，它就是给 Agent 用的工程文档，帮它把项目那本厚厚的“隐形的书”翻开，一页页读出来。现在这套框架在我的日常开发里稳定跑着，后面我打算把 L2 技能库再补一轮，重点解决依赖升级和性能剖析这类深度任务。如果你也在折腾自己的技能工作流，欢迎多交流，踩坑经验永远不嫌多。