cangjie-skill 阶段 4 压力测试实战用 darwin 兼容的 test-prompts.json 守住 Agent Skill 的调用精准度【免费下载链接】cangjie-skill把书、长视频、播客等高价值内容蒸馏成可执行的 Agent SkillsDistill high-value content from books, long-form videos, podcasts, and more into executable Agent Skills项目地址: https://gitcode.com/gh_mirrors/ca/cangjie-skill本篇技术指南讲解 cangjie-skillRIA-TV 蒸馏流水线中阶段 4「压力测试」的完整实现它验证每个被蒸馏出的 skill被调用的精准度与被调用后的输出质量是发布前唯一能暴露 trigger 问题的关口。读完你将掌握 darwin 兼容的test-prompts.json编写规范、独立 sub-agent 盲测方法、跨 skill 混淆测试设计以及「100% / ≥80% / 80%」三档通过率的回炉判定标准能够直接在自己蒸馏的 skill 包上落地这套可量化、可审计的验收体系。为什么阶段 4 是整条流水线的生死线在 SKILL.md 定义的 RIA-TV 流水线中阶段 4 夹在「阶段 3 链接」与「阶段 5 交付」之间前三个阶段负责把方法论做出来阶段 4 负责回答一个更残酷的问题——这个 skill 真的会在该被调用的时候被调用、不该被调用的时候忍住吗正如 methodology/06-stage4-pressure-test.md 开头所指出的A2Future Trigger未来触发场景是拆书里最难的环节。阶段 2 产出的 A2 决定了 skill frontmatter 中的description字段——而宿主Claude Code / Cursor 等正是只读namedescription来决定是否激活一个 skill 的这一点在 templates/SKILL.md.template 的注释中明确写明。也就是说一个 skill 做得再漂亮trigger 不准就等于不存在。更糟的是 trigger 过宽skill 会被乱调用在完全无关的场景里抢答最终用户对整套 skill 包失去信任。压力测试就是唯一能在发布前发现这两类问题的方法。从流水线整体看见 methodology/00-overview.md 的不变量清单阶段 4 与「三重验证」共同构成第 3 条不变量可验证每个 skill 必须通过三重验证 压力测试而第 4 条不变量可进化每个 skill 必须附带 darwin 兼容的 test-prompts.json也在此阶段落地——这正是本阶段标题中 (darwin 兼容) 的由来。评测原则独立 sub-agent 盲测优先压力测试要尽量模拟真实调用一个没有参与蒸馏过程、看不到预期答案的 agent面对用户 prompt 时是否会自然激活这个 skill。如果测试者就是蒸馏者本人心理锚定会让他高估自己的 trigger 质量——这是盲测存在的根本原因。优先做法有 sub-agent 能力时对每条测试 prompt 启动一个干净的 sub-agent资源有限时可对同一个 skill 的一组 prompt 启动一个干净 sub-agent。只给sub-agentskill 路径或 skill 内容、用户 prompt、可选的相邻 skill 列表。不给sub-agenttype、expected_behavior、notes、通过标准、主流程的判断。要求 sub-agent 输出三样东西would_trigger是否会触发、reason理由、if_triggered_action若触发会执行什么动作。主流程再把 sub-agent 输出和test-prompts.json的预期逐条对比统计通过率。降级方案无 sub-agent 能力时如果当前环境没有 sub-agent 能力才退回到主流程自测并且必须在test-results.md里标明这是 fallback 结果——它的可信度低于独立 sub-agent 盲测。这个降级要留痕的要求和 SKILL.md 阶段 1 的降级方案并行不可用时串行执行 5 个 extractor是同一设计哲学环境能力可以降级审计轨迹不能缺失。test-prompts.json 格式darwin-skill 兼容每个 skill 目录下必须有一个test-prompts.json。以下是 methodology/06-stage4-pressure-test.md 给出的完整示例以逆向思维skill 为例{ skill: inversion-thinking, version: 0.1.0, test_cases: [ { id: should-trigger-01, type: should_trigger, prompt: 我要决定要不要接这个新项目,列了一堆好处但还是没底, expected_behavior: 调用 inversion-thinking, 反问最不希望发生什么, notes: 正面场景: 决策纠结 }, { id: should-not-trigger-01, type: should_not_trigger, prompt: 帮我查一下这个 API 的参数, expected_behavior: 纯信息查询, 不应调用任何决策 skill, notes: 诱饵: 非决策场景 }, { id: edge-01, type: edge_case, prompt: 我在想晚饭吃什么, expected_behavior: 日常琐事, 不应调用 (虽然字面是决策), notes: 边界: 区分严肃决策和日常选择 } ] }对照仓库中的 templates/test-prompts.json.template正式模板在此基础上扩展了三个字段source_book形如{{BOOK_TITLE}} — {{AUTHOR}}把测试用例与来源内容绑定便于审计追溯darwin_compatible显式标记true声明本文件可直接被 darwin-skill 消费minimum_pass_rate模板默认0.8即通过率红线。模板底部的notes字段还固化了一条编写硬性约束至少 3 条 should_trigger 2 条 should_not_trigger 1 条 edge_case。全部 should_not_trigger 必须通过诱饵容错为 0且其中至少 1 条是同书兄弟 skill 的场景跨 skill 混淆测试。字段语义速查字段含义编写要点skill被测 skill 的 slug必须与SKILL.mdfrontmatter 的name一致kebab-caseversion测试集版本与 skill 版本联动进化后递增test_cases[].id用例唯一标识约定俗成用should-trigger-NN/should-not-trigger-NN/edge-NNtest_cases[].type用例类型三选一should_trigger/should_not_trigger/edge_casetest_cases[].prompt用户原话盲测时隐藏本字段以外的所有字段sub-agent 只能看到它test_cases[].expected_behavior期望行为应激活哪个 skill 期望执行的具体动作test_cases[].notes设计意图说明审计用标注正面场景 / 诱饵 / 边界的类型理由三类测试缺一不可类型数量目的should_trigger3–5 条该调用时是否调用should_not_trigger诱饵2–3 条不该调用时是否忍住edge_case1–3 条边界模糊场景的判断是否合理诱饵测试硬性要求没有诱饵测试的 skill 一律打回。只测 positive caseskill 总会看起来很好——因为所有 prompt 都朝着触发它的方向设计但实际部署后用户不会按你设计好的话术提问trigger 过宽的 skill 就会乱激活。诱饵测试就是给 skill 装上刹车验证它在不该出场时能忍住。跨 skill 混淆测试硬性要求这是诱饵中最容易被忽略、也最致命的一类诱饵中至少 1 条必须是应该触发同书另一个 skill的 prompt。原因在 methodology/06-stage4-pressure-test.md 中讲得很直白同一本书拆出的 10 个 skill 之间互相抢调用是部署后最常见的真实故障——只测完全无关的场景发现不了它。例如一本讲决策的书同时拆出了正向推理和逆向思维两个 skill用户在纠结要不要接项目时两个 skill 的 description 都可能命中这时谁该被激活盲测时的具体做法把整包所有 skill 的namedescription列表都交给 sub-agent让它做该激活哪一个的选择题而不只是要不要激活这一个的判断题。这与阶段 3 建立的related_skills关系见 methodology/05-stage3-zettelkasten.md 中的 depends-on / contrasts-with / composes-with 三类关系形成了呼应阶段 3 把 skill 之间的区分写清楚阶段 4 用跨 skill 诱饵验证这个区分真的能被一个旁观 agent 识别出来。执行流程五步走写测试对每个 skill按模板写test-prompts.json3–5 条 should_trigger 2–3 条诱饵 1–3 条边界诱饵中至少 1 条为跨 skill 混淆。盲测对每个 test_case 做独立盲测——隐藏type/expected_behavior/notes让 sub-agent 判断是否会调用这个 skill记录判断和理由would_trigger/reason/if_triggered_action。判卷主流程对照test-prompts.json逐条对比should_triggersub-agent 应明确调用该 skill且执行动作符合expected_behaviorshould_not_triggersub-agent 不应调用该 skill诱饵测试容错为 0一条都不能误触发edge_casesub-agent 的判断要符合expected_behavior中定义的边界理由。统计通过率按三档处理见下节。修复后重跑直到通过。通过率三档判定标准通过率处置100%接受≥80%分析失败 case决定是修 A2trigger还是修测试但修测试要警惕自我合理化80%必须回炉重做阶段 2不是小修注意 methodology/06-stage4-pressure-test.md 的用词强度不通过的必须回炉——不是表面修补description字段而是重做阶段 2 的 A2 / E / B。 也就是说低于 80% 意味着问题出在方法论构造层A2 触发场景没写准、E 执行步骤不可判、B 边界缺失改一行 description 只是自欺欺人。这条红线与 SKILL.md 质量红线第 4 条每个 skill 必须有 test-prompts.json且包含诱饵测试……其中至少 1 条是同书兄弟 skill 的场景互相咬合。判断修 skill 还是修测试失败之后不能盲目重跑要做归因——methodology/06-stage4-pressure-test.md 给出了三条判定准则失败的 case 暴露了 skilltrigger 描述有歧义→修 skill例如 A2 太宽像用户需要思考时这种 methodology/04-stage2-ria-plus.md 中明令禁止的坏示例必然导致误激活失败的 case 是一个你之前没想到的合理场景→可能需要修 skill以覆盖或明确排除说明 A2 的场景枚举不完整失败的 case 是你为了凑诱饵而设计过狠的场景例如把帮我查 API 参数这种和 skill 领域毫无关系的 prompt 硬塞进来当诱饵 →修测试但必须记录理由。第三条是修测试要警惕自我合理化的具体场景诱饵过狠本质上是测试设计问题不是 skill 质量问题但如果不记录理由修测试就会滑向为了让数据好看而放宽标准。所有修改都应在test-results.md中留下审计痕迹。输出与审计产物阶段 4 产生两个必须交付的文件skill-dir/test-prompts.json— darwin 兼容格式即上文格式skill-dir/test-results.md— 本次测试的通过率和失败分析审计用。对照 SKILL.md 的输出结构这两个文件位于books/book-slug/skill-slug/目录下与SKILL.md平级。同时注意 templates/SKILL.md.template 的审计信息段预留了**测试通过率**: {{%}} (详见 test-prompts.json)字段——也就是说每个 skill 的 SKILL.md 正文末尾要回填阶段 4 的测试通过率让这个 skill 是否经受过盲测对任何读者都一目了然。与阶段 5 交付的衔接测试不过绝不安装阶段 4 的验收结果直接决定阶段 5 的安装动作。在 methodology/07-stage5-deliver.md 中明确规定只安装通过阶段 4 测试的 skill—— 未通过的留在构建目录里回炉。阶段 5 安装完成后test-prompts.json还会继续发挥作用用户可以对已安装的 skill 用一句 should_trigger 的 prompt 做冒烟验证确认宿主能加载并触发而PIPELINE_STATE.md被标记为全部完成后整套产出可以一键喂给 darwin-skill 自动进化——darwin 正是用这里的 test-prompts.json 做 ratcheting棘轮式自动进化的darwin evolve books/slug/。这正是 README.md 生态定位中nuwa 蒸馏人cangjie 蒸馏书darwin 让它们持续进化三者咬合的关键接口。换句话说阶段 4 写下的测试用例不只服务于发布前的一次性验收它还是 skill 后续每一次进化迭代的回归测试基线——这也是version字段和minimum_pass_rate: 0.8存在的意义。实操建议汇总每个 skill 都要写即使是看起来很简单的 skill也必须配test-prompts.json这是 SKILL.md 质量红线没有例外诱饵宁多勿少should_not_trigger至少 2–3 条且容错为 0——一条误触发就回炉跨 skill 混淆必须测至少 1 条诱饵是应触发同书另一个 skill的场景盲测时把整包 skill 的 name description 列表交给 sub-agent 做选择题盲测信息隔离要彻底type/expected_behavior/notes一个都不能漏给 sub-agent降级要留痕没有 sub-agent 环境时的自测结果必须在test-results.md中标注为 fallback80% 就重做阶段 2不要用改 description 来骗过测试重做 A2 / E / B 才是正解结果要回填把通过率写进每个SKILL.md的审计信息段让验收状态可追溯、可引用。当所有 skill 全部通过压力测试后才允许进入阶段 5 交付生成面向读者的 DIGEST.md 精华长文、把 skill 安装到宿主 skills 目录并在之后向用户提供 darwin-skill 自动进化能力——至此阶段 4 为整个 RIA-TV 流水线的产出质量画上了最后一道保险。【免费下载链接】cangjie-skill把书、长视频、播客等高价值内容蒸馏成可执行的 Agent SkillsDistill high-value content from books, long-form videos, podcasts, and more into executable Agent Skills项目地址: https://gitcode.com/gh_mirrors/ca/cangjie-skill创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 cangjie-skill 阶段 4 压力测试实战：用 darwin 兼容的 test-prompts.json 守住 Agent Skill 的调用精准度
cangjie-skill 阶段 4 压力测试实战用 darwin 兼容的 test-prompts.json 守住 Agent Skill 的调用精准度【免费下载链接】cangjie-skill把书、长视频、播客等高价值内容蒸馏成可执行的 Agent SkillsDistill high-value content from books, long-form videos, podcasts, and more into executable Agent Skills项目地址: https://gitcode.com/gh_mirrors/ca/cangjie-skill本篇技术指南讲解 cangjie-skillRIA-TV 蒸馏流水线中阶段 4「压力测试」的完整实现它验证每个被蒸馏出的 skill被调用的精准度与被调用后的输出质量是发布前唯一能暴露 trigger 问题的关口。读完你将掌握 darwin 兼容的test-prompts.json编写规范、独立 sub-agent 盲测方法、跨 skill 混淆测试设计以及「100% / ≥80% / 80%」三档通过率的回炉判定标准能够直接在自己蒸馏的 skill 包上落地这套可量化、可审计的验收体系。为什么阶段 4 是整条流水线的生死线在 SKILL.md 定义的 RIA-TV 流水线中阶段 4 夹在「阶段 3 链接」与「阶段 5 交付」之间前三个阶段负责把方法论做出来阶段 4 负责回答一个更残酷的问题——这个 skill 真的会在该被调用的时候被调用、不该被调用的时候忍住吗正如 methodology/06-stage4-pressure-test.md 开头所指出的A2Future Trigger未来触发场景是拆书里最难的环节。阶段 2 产出的 A2 决定了 skill frontmatter 中的description字段——而宿主Claude Code / Cursor 等正是只读namedescription来决定是否激活一个 skill 的这一点在 templates/SKILL.md.template 的注释中明确写明。也就是说一个 skill 做得再漂亮trigger 不准就等于不存在。更糟的是 trigger 过宽skill 会被乱调用在完全无关的场景里抢答最终用户对整套 skill 包失去信任。压力测试就是唯一能在发布前发现这两类问题的方法。从流水线整体看见 methodology/00-overview.md 的不变量清单阶段 4 与「三重验证」共同构成第 3 条不变量可验证每个 skill 必须通过三重验证 压力测试而第 4 条不变量可进化每个 skill 必须附带 darwin 兼容的 test-prompts.json也在此阶段落地——这正是本阶段标题中 (darwin 兼容) 的由来。评测原则独立 sub-agent 盲测优先压力测试要尽量模拟真实调用一个没有参与蒸馏过程、看不到预期答案的 agent面对用户 prompt 时是否会自然激活这个 skill。如果测试者就是蒸馏者本人心理锚定会让他高估自己的 trigger 质量——这是盲测存在的根本原因。优先做法有 sub-agent 能力时对每条测试 prompt 启动一个干净的 sub-agent资源有限时可对同一个 skill 的一组 prompt 启动一个干净 sub-agent。只给sub-agentskill 路径或 skill 内容、用户 prompt、可选的相邻 skill 列表。不给sub-agenttype、expected_behavior、notes、通过标准、主流程的判断。要求 sub-agent 输出三样东西would_trigger是否会触发、reason理由、if_triggered_action若触发会执行什么动作。主流程再把 sub-agent 输出和test-prompts.json的预期逐条对比统计通过率。降级方案无 sub-agent 能力时如果当前环境没有 sub-agent 能力才退回到主流程自测并且必须在test-results.md里标明这是 fallback 结果——它的可信度低于独立 sub-agent 盲测。这个降级要留痕的要求和 SKILL.md 阶段 1 的降级方案并行不可用时串行执行 5 个 extractor是同一设计哲学环境能力可以降级审计轨迹不能缺失。test-prompts.json 格式darwin-skill 兼容每个 skill 目录下必须有一个test-prompts.json。以下是 methodology/06-stage4-pressure-test.md 给出的完整示例以逆向思维skill 为例{ skill: inversion-thinking, version: 0.1.0, test_cases: [ { id: should-trigger-01, type: should_trigger, prompt: 我要决定要不要接这个新项目,列了一堆好处但还是没底, expected_behavior: 调用 inversion-thinking, 反问最不希望发生什么, notes: 正面场景: 决策纠结 }, { id: should-not-trigger-01, type: should_not_trigger, prompt: 帮我查一下这个 API 的参数, expected_behavior: 纯信息查询, 不应调用任何决策 skill, notes: 诱饵: 非决策场景 }, { id: edge-01, type: edge_case, prompt: 我在想晚饭吃什么, expected_behavior: 日常琐事, 不应调用 (虽然字面是决策), notes: 边界: 区分严肃决策和日常选择 } ] }对照仓库中的 templates/test-prompts.json.template正式模板在此基础上扩展了三个字段source_book形如{{BOOK_TITLE}} — {{AUTHOR}}把测试用例与来源内容绑定便于审计追溯darwin_compatible显式标记true声明本文件可直接被 darwin-skill 消费minimum_pass_rate模板默认0.8即通过率红线。模板底部的notes字段还固化了一条编写硬性约束至少 3 条 should_trigger 2 条 should_not_trigger 1 条 edge_case。全部 should_not_trigger 必须通过诱饵容错为 0且其中至少 1 条是同书兄弟 skill 的场景跨 skill 混淆测试。字段语义速查字段含义编写要点skill被测 skill 的 slug必须与SKILL.mdfrontmatter 的name一致kebab-caseversion测试集版本与 skill 版本联动进化后递增test_cases[].id用例唯一标识约定俗成用should-trigger-NN/should-not-trigger-NN/edge-NNtest_cases[].type用例类型三选一should_trigger/should_not_trigger/edge_casetest_cases[].prompt用户原话盲测时隐藏本字段以外的所有字段sub-agent 只能看到它test_cases[].expected_behavior期望行为应激活哪个 skill 期望执行的具体动作test_cases[].notes设计意图说明审计用标注正面场景 / 诱饵 / 边界的类型理由三类测试缺一不可类型数量目的should_trigger3–5 条该调用时是否调用should_not_trigger诱饵2–3 条不该调用时是否忍住edge_case1–3 条边界模糊场景的判断是否合理诱饵测试硬性要求没有诱饵测试的 skill 一律打回。只测 positive caseskill 总会看起来很好——因为所有 prompt 都朝着触发它的方向设计但实际部署后用户不会按你设计好的话术提问trigger 过宽的 skill 就会乱激活。诱饵测试就是给 skill 装上刹车验证它在不该出场时能忍住。跨 skill 混淆测试硬性要求这是诱饵中最容易被忽略、也最致命的一类诱饵中至少 1 条必须是应该触发同书另一个 skill的 prompt。原因在 methodology/06-stage4-pressure-test.md 中讲得很直白同一本书拆出的 10 个 skill 之间互相抢调用是部署后最常见的真实故障——只测完全无关的场景发现不了它。例如一本讲决策的书同时拆出了正向推理和逆向思维两个 skill用户在纠结要不要接项目时两个 skill 的 description 都可能命中这时谁该被激活盲测时的具体做法把整包所有 skill 的namedescription列表都交给 sub-agent让它做该激活哪一个的选择题而不只是要不要激活这一个的判断题。这与阶段 3 建立的related_skills关系见 methodology/05-stage3-zettelkasten.md 中的 depends-on / contrasts-with / composes-with 三类关系形成了呼应阶段 3 把 skill 之间的区分写清楚阶段 4 用跨 skill 诱饵验证这个区分真的能被一个旁观 agent 识别出来。执行流程五步走写测试对每个 skill按模板写test-prompts.json3–5 条 should_trigger 2–3 条诱饵 1–3 条边界诱饵中至少 1 条为跨 skill 混淆。盲测对每个 test_case 做独立盲测——隐藏type/expected_behavior/notes让 sub-agent 判断是否会调用这个 skill记录判断和理由would_trigger/reason/if_triggered_action。判卷主流程对照test-prompts.json逐条对比should_triggersub-agent 应明确调用该 skill且执行动作符合expected_behaviorshould_not_triggersub-agent 不应调用该 skill诱饵测试容错为 0一条都不能误触发edge_casesub-agent 的判断要符合expected_behavior中定义的边界理由。统计通过率按三档处理见下节。修复后重跑直到通过。通过率三档判定标准通过率处置100%接受≥80%分析失败 case决定是修 A2trigger还是修测试但修测试要警惕自我合理化80%必须回炉重做阶段 2不是小修注意 methodology/06-stage4-pressure-test.md 的用词强度不通过的必须回炉——不是表面修补description字段而是重做阶段 2 的 A2 / E / B。 也就是说低于 80% 意味着问题出在方法论构造层A2 触发场景没写准、E 执行步骤不可判、B 边界缺失改一行 description 只是自欺欺人。这条红线与 SKILL.md 质量红线第 4 条每个 skill 必须有 test-prompts.json且包含诱饵测试……其中至少 1 条是同书兄弟 skill 的场景互相咬合。判断修 skill 还是修测试失败之后不能盲目重跑要做归因——methodology/06-stage4-pressure-test.md 给出了三条判定准则失败的 case 暴露了 skilltrigger 描述有歧义→修 skill例如 A2 太宽像用户需要思考时这种 methodology/04-stage2-ria-plus.md 中明令禁止的坏示例必然导致误激活失败的 case 是一个你之前没想到的合理场景→可能需要修 skill以覆盖或明确排除说明 A2 的场景枚举不完整失败的 case 是你为了凑诱饵而设计过狠的场景例如把帮我查 API 参数这种和 skill 领域毫无关系的 prompt 硬塞进来当诱饵 →修测试但必须记录理由。第三条是修测试要警惕自我合理化的具体场景诱饵过狠本质上是测试设计问题不是 skill 质量问题但如果不记录理由修测试就会滑向为了让数据好看而放宽标准。所有修改都应在test-results.md中留下审计痕迹。输出与审计产物阶段 4 产生两个必须交付的文件skill-dir/test-prompts.json— darwin 兼容格式即上文格式skill-dir/test-results.md— 本次测试的通过率和失败分析审计用。对照 SKILL.md 的输出结构这两个文件位于books/book-slug/skill-slug/目录下与SKILL.md平级。同时注意 templates/SKILL.md.template 的审计信息段预留了**测试通过率**: {{%}} (详见 test-prompts.json)字段——也就是说每个 skill 的 SKILL.md 正文末尾要回填阶段 4 的测试通过率让这个 skill 是否经受过盲测对任何读者都一目了然。与阶段 5 交付的衔接测试不过绝不安装阶段 4 的验收结果直接决定阶段 5 的安装动作。在 methodology/07-stage5-deliver.md 中明确规定只安装通过阶段 4 测试的 skill—— 未通过的留在构建目录里回炉。阶段 5 安装完成后test-prompts.json还会继续发挥作用用户可以对已安装的 skill 用一句 should_trigger 的 prompt 做冒烟验证确认宿主能加载并触发而PIPELINE_STATE.md被标记为全部完成后整套产出可以一键喂给 darwin-skill 自动进化——darwin 正是用这里的 test-prompts.json 做 ratcheting棘轮式自动进化的darwin evolve books/slug/。这正是 README.md 生态定位中nuwa 蒸馏人cangjie 蒸馏书darwin 让它们持续进化三者咬合的关键接口。换句话说阶段 4 写下的测试用例不只服务于发布前的一次性验收它还是 skill 后续每一次进化迭代的回归测试基线——这也是version字段和minimum_pass_rate: 0.8存在的意义。实操建议汇总每个 skill 都要写即使是看起来很简单的 skill也必须配test-prompts.json这是 SKILL.md 质量红线没有例外诱饵宁多勿少should_not_trigger至少 2–3 条且容错为 0——一条误触发就回炉跨 skill 混淆必须测至少 1 条诱饵是应触发同书另一个 skill的场景盲测时把整包 skill 的 name description 列表交给 sub-agent 做选择题盲测信息隔离要彻底type/expected_behavior/notes一个都不能漏给 sub-agent降级要留痕没有 sub-agent 环境时的自测结果必须在test-results.md中标注为 fallback80% 就重做阶段 2不要用改 description 来骗过测试重做 A2 / E / B 才是正解结果要回填把通过率写进每个SKILL.md的审计信息段让验收状态可追溯、可引用。当所有 skill 全部通过压力测试后才允许进入阶段 5 交付生成面向读者的 DIGEST.md 精华长文、把 skill 安装到宿主 skills 目录并在之后向用户提供 darwin-skill 自动进化能力——至此阶段 4 为整个 RIA-TV 流水线的产出质量画上了最后一道保险。【免费下载链接】cangjie-skill把书、长视频、播客等高价值内容蒸馏成可执行的 Agent SkillsDistill high-value content from books, long-form videos, podcasts, and more into executable Agent Skills项目地址: https://gitcode.com/gh_mirrors/ca/cangjie-skill创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考