Skill Forge v2：基于自主实验循环的AI技能与代码自动化优化引擎

1. 项目概述：一个让AI技能与代码库自我进化的“锻造炉”

如果你正在使用Claude Cowork这类AI协作平台，或者手头有一个需要持续优化的代码项目，你肯定体会过反复手动调整、测试、评估的繁琐。每次修改都像是一次赌博，你无法确定这次调整是让效果提升了，还是引入了新的问题。Skill Forge v2 就是为了终结这种低效循环而生的。它本质上是一个自主实验循环系统，像一个不知疲倦的“锻造师”，能自动分析你技能或代码的弱点，提出修改假设，执行测试，并根据客观指标决定保留改进还是回退。你可以把它看作一个专为AI技能和通用代码库设计的“自动驾驶”优化引擎。

这个项目的核心价值在于将主观、模糊的“优化”过程，转变为客观、可重复、可度量的科学实验。无论是优化一个Claude Skill的指令文档（SKILL.md），还是提升一个Python脚本的性能指标，Skill Forge都能通过其严谨的“假设-实验-评估”循环，在无人值守的情况下（比如你睡觉时）持续寻找更优解。它深受Andrej Karpathy的“autoresearch”理念启发，但将应用场景从机器学习训练代码扩展到了更广泛的自然语言指令和通用代码优化领域。

2. 核心架构与双模式设计解析

Skill Forge v2的架构清晰地区分了两种核心工作模式，这决定了它能处理什么类型的问题，以及如何进行处理。理解这两种模式是有效使用它的前提。

2.1 技能模式：专为Claude Cowork技能优化而生

技能模式是Skill Forge的“原生”模式，专门针对Claude Cowork的Skill进行优化。它的优化对象是一个名为SKILL.md的文件，这是定义Claude技能行为的核心指令文档。

核心工作流：分析 → 提出假设 → 修改SKILL.md → 评估 → 评分 → 保留/回退 → 重复

在这个模式下，评估的依据是一组预先定义的“评估断言”。这些断言本质上是一系列测试用例，每个用例包含一个输入提示和一个期望的输出标准。例如，对于一个“文章润色”技能，一个评估断言可能是：“输入‘这个产品很好用’，输出应包含更丰富的形容词和具体的使用场景描述。” Skill Forge会运行这些断言，检查技能的实际输出是否符合预期，并计算一个通过率。

为什么选择技能模式？当你需要提升的是一个AI智能体的“软技能”——即它理解指令、遵循流程、输出特定格式内容的能力时，技能模式是最佳选择。它优化的不是代码的执行效率，而是自然语言指令的清晰度、完备性和引导效果。这种优化非常微妙，通常需要大量的人工试错，而Skill Forge自动化了这个过程。

2.2 通用模式：将任何文件与任何指标挂钩

通用模式极大地扩展了Skill Forge的适用范围。它不再局限于SKILL.md和评估断言，而是允许你指定任何文件作为优化目标，并指定任何能返回一个数字的Shell命令作为评估指标。

核心工作流：分析 → 提出假设 → 修改目标文件 → 运行度量命令 → 评分 → 保留/回退 → 重复

这意味着你可以优化一个Python脚本（train.py），用python train.py --eval命令的输出来衡量模型准确率；可以优化一个Web服务器的配置文件（nginx.conf），用ab -n 100 -c 10 http://localhost/命令的“每秒请求数”作为指标；甚至可以优化一个Markdown文档，用一个自定义脚本检查其可读性分数（例如Flesch-Kincaid指数）。

模式选择的实操要点：

• 自动检测：Skill Forge通常能根据目标路径是否包含SKILL.md来自动选择模式。但明确指定模式可以避免意外。
• 指标命令的设计是关键：在通用模式下，你提供的Shell命令必须满足两个条件：1) 执行成功（退出码为0）；2) 输出中包含一个可解析的数字（整数或浮点数）。这个数字就是优化的“北极星”。你需要确保这个命令稳定、可重复，并且其输出的数字变化能真实反映你关心的质量维度。
• 方向性：你必须明确告诉系统，这个数字是“越高越好”（例如准确率、吞吐量）还是“越低越好”（例如错误率、延迟）。这通过metric_direction参数设置。

3. 深入核心：三大智能体与实验循环

Skill Forge的自动化能力并非来自一个单一的、模糊的AI，而是由三个职责分明的“智能体”协同工作实现的。这种模块化设计使得每个环节都清晰可控，也便于未来扩展或替换某个组件。

3.1 假设智能体：扮演“科学家”的分析师

假设智能体是整个循环的“大脑”。它的任务不是直接修改文件，而是分析现状，诊断问题，并提出一个可验证的科学假设。

输入：它接收当前版本的SKILL.md（或目标文件）、上一轮实验的评分结果、完整的实验历史记录，以及一个关键的“覆盖矩阵”。覆盖矩阵记录了哪些类型的修改已经被尝试过（例如：“改进了工作流程描述”、“增加了边界案例处理”、“优化了输出格式”）。

工作流程：

1. 失败分析：仔细审查那些未通过的评估断言或较低的指标分数，尝试归纳失败的模式。是某个步骤的指令模糊？是缺少对特定输入类型的处理？还是效率低下？
2. 查阅历史：避免重复劳动。检查覆盖矩阵，看看针对当前诊断出的问题类型，是否已有成功的修改方案可以借鉴，或者哪些类型的修改还未被充分探索。
3. 提出假设：基于以上分析，形成一个具体的、可操作的假设。例如：“假设：在SKILL.md的‘校对’步骤中，增加一个关于‘处理中文引号与英文引号混用’的具体子步骤，将能提高对混合排版文本的处理通过率。”
4. 生成修改提案：将假设转化为对“外科医生”（突变智能体）的明确指令，指出应该在文件的哪个部分、以何种方式进行修改。

实操心得：假设的质量决定上限假设智能体的输出是整个实验的起点。一个模糊的假设（如“让指令更清晰”）会导致后续修改漫无目的。而一个具体、可证伪的假设（如“在第三步增加一个检查列表，明确要求核对日期、金额、人名三项”）能引导突变智能体做出精准的修改。在“引导模式”下，你可以在此环节介入，审核并修正假设，这能显著提升实验效率。

3.2 突变智能体：扮演“外科医生”的执行者

突变智能体是“双手”。它接收假设智能体发来的、带有具体修改提案的指令，然后对目标文件进行一次且仅一次聚焦的修改。

核心原则：最小化变更它的设计哲学是“一次只改变一件事”。这源于科学实验的“控制变量法”。如果一次修改同时调整了多个部分，当评分结果变化时，你将无法确定是哪个改动起了作用（或是引起了问题）。因此，突变智能体会严格遵循提案，可能只是增加一个句子、修改一个参数，或者调整一段代码的逻辑。

输出：它会产生两个关键输出：

1. 修改后的文件：这是实验的对象。
2. 修改文档：详细记录了修改的位置、修改前的原文、修改后的文本以及修改意图。这份文档对于回溯实验过程和理解每次改变的贡献至关重要。

注意事项：避免“手术事故”尽管是AI执行，但修改也可能引入语法错误、格式混乱或逻辑冲突。Skill Forge v2通过“预运行验证门”来提前发现这类问题。在正式进入评估循环前，系统会用修改后的文件运行一次最基本的检查（例如，对于技能模式，运行一个最简单的评估；对于通用模式，执行一次度量命令）。如果连这个检查都无法通过（命令崩溃或报错），系统会中止本次实验，避免在明显错误的状态下进行无意义的评估。

3.3 评分智能体与决策逻辑

在技能模式下，评分智能体扮演“法官”。它使用那部分从未在假设生成阶段使用过的、被“留出”的测试评估集（通常占40%），对修改后技能的输出进行盲审打分。分数是0到1之间的标准化值。

复合分数计算： 默认的复合分数公式是：复合分数 = 断言通过率 × 0.80 + 效率分数 × 0.20。

• 断言通过率（权重80%）：这是核心质量指标，衡量技能是否满足了功能要求。
• 效率分数（权重20%）：这可能衡量响应速度、输出简洁度等。这个权重分配强调了“功能正确”优先于“形式优美”。

更高级的评判：LLM作为法官对于输出质量难以用简单规则判断的场景（如文章创意性、语气友好度），可以启用use_comparator选项。此时，评分智能体会让一个LLM（如Claude）对修改前和修改后的输出进行“盲比”（不知道哪个是哪个），判断哪个更好。此时分数公式变为：复合分数 = 断言通过率 × 0.50 + LLM评判分 × 0.30 + 效率分 × 0.20。这引入了人类偏好的主观衡量，但成本更高。

保留/回退决策： 决策并非只看分数高低，而是看相对于“基线”（当前最佳版本）的变化。

• 保留：如果新分数 > 基线分数 + 0.02（improvement_threshold）。这是一个明确的、显著的进步。
• 回退：如果新分数 < 基线分数 - 0.05（regression_threshold）。这是一个明显的退步，必须丢弃。
• 中性/保留：如果分数变化在[-0.05, +0.02]之间。系统会倾向于保留新版本，因为这可能包含了虽未显著提升但可能有潜在价值的微调，为后续优化奠定了基础。

这个决策机制非常稳健，它防止了由于随机波动导致的频繁来回切换，只接受确切的进步，并果断拒绝退步。

4. 实战部署与操作指南

理解了原理，我们来一步步看看如何实际使用Skill Forge v2。我将以优化一个虚构的“技术博客助手”Claude技能为例，贯穿整个流程。

4.1 环境准备与技能安装

首先，你需要一个运行Claude Cowork的环境。Skill Forge本身也是一个Claude Skill，因此安装方式与普通技能无异。

1. 定位技能目录：在你的机器上，找到Claude Cowork的技能存放目录。通常路径是~/.skills/skills/。
2. 克隆或复制：将整个skill-forge项目文件夹复制到上述技能目录中。最终路径应类似于~/.skills/skills/skill-forge/。
3. 验证安装：打开Claude Cowork，你应该能在技能列表中找到或通过@提及的方式调用skill-forge。

注意：确保你的Claude Cowork环境具有执行Shell命令的权限，因为Skill Forge在通用模式下需要调用你定义的度量命令，在技能模式下也可能需要调用外部脚本进行评估。

4.2 交互式设置向导详解

Skill Forge v2一个非常用户友好的改进是引入了6步交互式设置向导。这个向导会引导你完成所有必要配置，并在每一步进行验证，确保配置正确无误。

第1步：选择执行模式与目标

• 内容：系统会询问你希望运行在自动模式还是引导模式。对于初次使用或非常重要的技能，强烈建议从引导模式开始。然后，你需要指定要优化的目标，例如“我的blog-helper技能”。
• 验证门：系统会检查目标是否存在。如果选择引导模式，后续会在5个关键检查点暂停等待你的确认。

第2步：定义优化范围

• 技能模式：系统自动在目标技能目录中寻找SKILL.md文件。
• 通用模式：你需要提供一个文件匹配模式（如src/*.py），系统会检查是否至少匹配到一个文件。
• 实操技巧：在通用模式下，尽量使用具体的文件路径而非模糊的通配符，以避免意外优化无关文件。

第3步：定义评估指标（核心步骤）这是最关键的一步，决定了优化的方向。

• 技能模式：你需要提供至少3个评估断言。系统会自动将它们按6：4的比例分为“训练集”（用于生成假设）和“测试集”（用于最终评分）。例如：

  [ { "input": "写一段关于Python装饰器的简介，面向初学者。", "assertions": ["输出中包含‘@’符号的用法示例", "输出避免使用‘元编程’等高级术语", "字数在200-300字之间"] }, { "input": "帮我润色这段产品发布邮件：'新品上线，功能强大，快来购买。'", "assertions": ["输出语气更正式、有说服力", "包含具体的产品功能点", "有明确的行动号召"] } ]

• 通用模式：你需要提供一个能输出数字的Shell命令。例如，如果你优化的是一个API响应时间，命令可能是：curl -o /dev/null -s -w '%{time_total}\n' http://localhost:8080/api/test。
• 验证门：系统会立即运行一次你定义的评估（或度量命令），确保其能成功执行并返回一个可解析的数字。如果失败，向导会中止并给出错误提示，让你修正。

第4步：设置优化方向

• 内容：明确告诉系统，对于上一步得到的数字，是希望它越高越好（higher_is_better）还是越低越好（lower_is_better）。例如，准确率是越高越好，错误率是越低越好。
• 验证：这是一个简单的确认步骤，防止方向设置错误导致优化南辕北辙。

第5步：预运行验证

• 内容：这是正式实验前的最后一次“彩排”。系统会用当前的基线文件，完整运行一遍评估流程（技能模式跑所有评估，通用模式执行度量命令）。
• 验证门：必须成功运行且输出合规。这个步骤能提前发现环境依赖缺失、脚本路径错误、API密钥无效等基础问题。如果失败，向导会给出详细的错误信息，并允许你返回上一步修改配置。

第6步：确认配置

• 内容：系统会展示一份完整的配置摘要，包括模式、目标、评估指标、参数（最大实验次数、时间预算等）供你最终审核。
• 操作：确认后，实验循环才真正开始。

这个向导设计极大地降低了使用门槛，通过层层验证保证了实验启动时处于一个健康的状态。

4.3 运行实验与监控

配置完成后，实验循环就自动开始了。你可以通过几种方式监控进展：

1. 实时TSV日志：在项目生成的专属工作空间目录（如blog-helper-skill-forge/）下，会有一个experiment-log.tsv文件。这是一个制表符分隔的平面文件，每行记录一次实验的核心信息。你可以用tail -f experiment-log.tsv命令在终端实时滚动查看。

   timestamp experiment hypothesis_summary before after delta decision 2023-10-27T14:30 exp-001 增加对“代码示例”格式的明确要求 0.72 0.75 +0.03 KEEP 2023-10-27T14:45 exp-002 尝试简化开篇引导句 0.75 0.71 -0.04 REVERT

   这种格式非常适合机器处理和快速人眼扫描，是v2版本一个非常实用的改进。

2. 覆盖矩阵：工作空间下的coverage-matrix.json文件（或通过生成的晨报查看）会动态更新。它告诉你系统正在探索哪些改进方向，以及哪些方向已经饱和。这能让你直观感受到优化的进程，避免系统在原地打转。

3. 详细实验记录：每个实验都有一个独立的文件夹（如experiments/exp-001/），里面保存了假设、修改内容、评分详情和每次评估运行的原始输出。这是进行深度分析和调试的宝库。

设置无人值守运行： 真正的威力在于无人值守。你可以通过Claude Cowork的调度任务功能，或简单的系统Cron Job，让Skill Forge在夜间运行。

# 一个简化的Cron Job示例，每天凌晨2点运行，最多10次实验，时间预算2小时 0 2 * * * cd /path/to/your/project && claude-cowork "使用skill-forge技能，以自动模式优化我的‘blog-helper’技能，最大实验次数10，时间预算120分钟"

第二天早上，一份完整的morning-report.md报告就会等着你，告诉你技能经过一夜“锻造”后，性能提升了多少，以及具体发生了哪些变化。

5. 高级策略与核心机制剖析

Skill Forge不仅仅是一个简单的自动化脚本，它内部集成了一系列确保优化有效、避免陷阱的智能策略。

5.1 探索与利用的平衡策略

这是模仿强化学习的一个关键思想。系统不会盲目地只盯着当前最有效的修改类型。

• 早期阶段（第1-3轮实验）：探索优先。系统会查看覆盖矩阵，优先尝试那些还从未被尝试过的改进类别（例如，从未触及过的“格式化”类别）。这有助于广泛搜索潜在的优化空间。
• 中期阶段（第4-7轮实验）：混合策略。系统开始平衡探索新类别和深化已有成功类别（利用）。它会参考不同类别下的历史最佳改进分数（Best Delta）。
• 后期阶段（第8轮及以后）：利用优先。当实验次数接近上限时，系统会集中火力在那些已经证明能带来最大提升的改进类别上，力求将性能推到极限。

这个策略有效防止了系统过早收敛于一个局部最优解，鼓励了创新性的探索。

5.2 严防过拟合的多重保障

过拟合是优化中的大敌，即修改只对用于评估的特定例子有效，却损害了整体的泛化能力。Skill Forge设计了四道防线：

1. 训练/测试集分离：这是最重要的防线。用于给假设智能体分析问题的“训练集”评估，和用于最终打分的“测试集”评估是完全分开的。任何修改必须能在未参与分析的测试集上也能提升分数，才算真正有效。
2. 泛化性解释要求：假设智能体在提出修改建议时，必须附带说明“为什么这个修改能普遍提升技能，而不仅仅是针对当前失败的例子”。这迫使思考停留在原则层面。
3. 评估轮换：在技能模式下，每进行5次实验，系统会要求LLM生成一批全新的评估查询（保持相同的断言标准）。这相当于引入了新的“考题”，防止技能死记硬背旧题。
4. 覆盖矩阵多样性：通过追踪不同类别的修改，系统会主动避免在单一类别上过度实验，鼓励多样化的改进，这本身也有助于泛化。

5.3 健壮的崩溃处理机制

在长时间的自动化运行中，什么事情都可能发生：API调用超时、评估脚本有Bug、甚至系统资源不足。Skill Forge的崩溃处理机制确保了单点故障不会导致整个任务崩溃。

1. 错误分类：当一次评估运行崩溃时，系统会首先尝试解析错误信息，将其分类为：目标技能脚本错误、基础设施错误（如网络超时）、还是评估逻辑本身错误。
2. 差异化处理：
   • 技能脚本错误：如果崩溃是因为修改后的SKILL.md导致技能本身无法运行，这是一个严重信号。系统会将本次实验的该评估项分数记为0（相当于一次重大失败），并继续其他评估。
   • 基础设施错误：如果是网络等问题，系统会重试一次。如果仍然失败，则跳过该评估项，不影响其他项进行。
   • 评估逻辑错误：如果评估脚本自身有Bug，系统会将其从本次评分中排除，并记录日志。
3. 连续崩溃熔断：如果连续3次实验都在一开始就崩溃（例如，每次的修改都导致技能完全无法执行），系统会主动暂停，并生成警报报告。这通常意味着假设智能体提出了破坏性极强的修改，需要人工干预。
4. 跳过与继续：处理完一个评估项的崩溃后，循环会继续处理下一个评估项或进行下一个实验。一次崩溃不会“杀死”整个运行任务。

6. 配置参数详解与调优建议

Skill Forge提供了丰富的配置参数，让你可以精细控制优化过程。以下是一些关键参数及其调优建议：

个人调优经验：

• 对于全新的、定义模糊的技能，建议先用guided（引导模式）跑2-3轮，人工审核假设和修改，帮助系统理解什么是“好”的修改方向。
• 在技能模式下，评估断言的质量至关重要。断言要具体、可验证（例如“输出必须包含‘步骤一、步骤二’这样的列表”，而不是“输出要有条理”）。宁可用5个精确的断言，也不用20个模糊的断言。
• 在通用模式下，度量命令的稳定性和低方差是关键。确保每次运行命令，在输入不变的情况下，输出数字波动很小。如果方差太大，优化过程会充满噪声，难以收敛。

7. 真实案例与效果评估

项目文档中提到了三个内部测试案例，这些案例很好地展示了Skill Forge在不同场景下的能力：

1. humanizer（文本人性化技能）：

   • 问题：技能旨在将生硬的AI文本改写得更像人类，但效果不稳定。
   • 过程：经过3轮自主实验。
   • 结果：复合分数从0.74提升至0.90（提升21.6%）。
   • 关键改进：假设智能体发现原指令对“人格化”的描述模糊。它提出的获胜修改是：将“添加人格”作为一个独立的工作流程步骤，并给出了具体的、可操作的人格特征检查列表（例如：“检查是否使用了口语化词汇？”、“是否加入了个人观点或感叹？”）。这使得技能的输出一致性大幅提高。

2. fachbuch-lektorat（德语技术书籍编辑技能）：

   • 问题：技能在处理德语中正式“wir”（我们）与个人“ich”（我）的混用时表现不佳。
   • 过程：3轮实验。
   • 结果：评估断言通过率从87%提升至100%。
   • 关键改进：系统在SKILL.md中增加了一个具体的工作示例，清晰地展示了当一段文本混合使用“wir”和“ich”时，应如何统一为其中一种风格。通过实例教学，极大地提升了技能处理此类边缘案例的能力。

3. was-bisher-geschah（AI新闻简报技能）：

   • 问题：技能生成的新闻摘要有时会超过LinkedIn的字符限制，且行动号召不明确。
   • 过程：仅1轮实验。
   • 结果：通过率从93%提升至100%。
   • 关键改进：突变智能体在指令中明确加入了LinkedIn帖文的字符数限制提醒，并在总结每个新闻条目后，强制插入一个明确的行动提示模板（如“点击链接阅读全文”）。这个简单的修改直接解决了两个明确的评估失败点。

从这些案例可以看出，Skill Forge最擅长解决的是指令模糊、缺失具体约束或缺少处理范例所导致的问题。它能将人类“只可意会”的优化点，转化为对指令文档具体、可衡量的增删改。

8. 项目结构与工作空间管理

清晰的目录结构是项目可维护性的基础。Skill Forge自身和它运行时生成的工作空间都遵循良好的组织规范。

技能本体结构 (skill-forge/)：

• SKILL.md：核心技能指令文件，定义了Skill Forge如何与用户交互、调用各个智能体。
• agents/：存放三个核心智能体（假设、突变、评分）的详细指令文件。这是技能逻辑的核心。
• scripts/composite_score.py：一个独立的Python脚本/库，负责计算复合分数、管理TSV日志和覆盖矩阵。这种设计意味着评分逻辑可以脱离Claude环境独立运行或测试。
• templates/morning_report.md：晨报生成模板。你可以自定义这个模板来改变报告格式。
• references/：包含架构说明和定时任务模板等深度文档。
• examples/：存放真实的实验日志示例，供用户参考。

运行时工作空间结构 (<target>-skill-forge/)： 每次运行都会生成一个独立的工作空间，这是实验可重复性的关键。所有状态都保存在这里。

• config.json：完整保存了本次运行的所有配置参数。凭这个文件可以精确复现实验。
• evals.json：保存了使用的所有评估断言及其训练/测试划分。
• experiment-log.tsv和coverage-matrix.json：实时监控文件。
• snapshots/：保存每个实验轮次后的文件版本（v0是基线，v1是第一次修改后，以此类推）。你可以随时回滚到任何版本。
• experiments/exp-001/：每个实验的详细档案，包含假设、修改、评分等所有中间数据。
• history.json：分数随时间变化的序列，可用于绘制学习曲线。
• morning-report.md：实验结束后生成的人类可读总结报告。

管理建议：

• 定期清理旧的工作空间。每个工作空间可能包含大量评估运行记录，占用空间。
• 将重要的config.json和最终优化的SKILL.md（或目标文件）备份到版本控制系统（如Git）中。
• 利用snapshots/目录进行差异比较，理解每次修改的具体内容。

9. 局限性与适用边界

尽管Skill Forge非常强大，但它并非万能。清楚它的边界能帮助你更好地应用它。

1. 依赖于可量化的评估指标：这是最根本的限制。如果你无法将你的优化目标转化为一个（或一组）可自动执行并输出数字的测试，那么Skill Forge就无法工作。例如，“让文章更有文采”是一个模糊目标，除非你能定义“文采”的自动化度量标准（如通过某个文本风格模型打分）。
2. 局部搜索，非全局重构：它基于当前版本进行小步、迭代的修改。它无法进行大刀阔斧的重构或架构变更。如果技能或代码存在根本性的设计缺陷，可能需要人工先进行一轮大的调整，再用Skill Forge做精细优化。
3. 计算与成本：每次实验都需要运行全部评估（可能调用LLM或执行外部命令）。在技能模式下，如果评估很多且复杂，运行成本（API调用）和时间会显著增加。需要合理设置max_experiments和time_budget。
4. 评估集的质量决定天花板：“垃圾进，垃圾出”。如果评估断言设计得不好，不能代表真实场景，那么优化出来的技能可能只是“应试”高手，在实际使用中表现不佳。评估集需要精心设计和维护。
5. 创意与突破性创新：当前的机制更擅长“优化”而非“发明”。它可以在给定的框架内找到更好的参数或表述，但很难无中生有地创造出全新的工作流程或解决范式。

最适合的场景：

• 优化已有Claude技能的指令清晰度、完备性和边界案例处理。
• 微调代码脚本的性能参数（如超参数）、配置选项。
• 在拥有稳定自动化测试套件的前提下，改进代码库的局部实现。
• 探索不同提示词或配置对某个固定评估指标的影响。

Skill Forge v2代表了一种强大的范式：将软件工程中的持续集成/测试理念，与AI驱动的自动化探索相结合。它不是一个完全取代人类工程师的“银弹”，而是一个不知疲倦、严格遵循实验方法的“超级助手”。通过将优化过程形式化、自动化，它把人类从重复的试错中解放出来，让我们能更专注于定义问题、设计评估标准和解读最终结果——这些更需要创造力和判断力的工作。