当 AI 能补全一个函数时，开发者需要判断这段代码是否正确。当 AI 能接手一个完整任务时，需要考虑的事情就更多了。它从哪里理解需求，怎么找到项目约束，什么时候应该继续尝试，又凭什么认定任务已经完成？
这也是 Luis Velasco 在 CONVEX 26 演讲中讨论的起点。他把这类工作称为 meta-SWE，也就是元软件工程。我们需要设计好环境和工作流，让代理能够持续完成软件工程任务。随着代理承担的工作增加，开发者要设计的对象也从代码扩展到了上下文、执行流程和评估机制。
Luis Velasco 的工作背景
Luis Velasco 是 OpenAI 的 Forward Deployed Engineer（FDE，前沿部署工程师）。他的工作涉及 AI 代理、长时程工作流，以及模型与企业数据的集成，重点是将 AI 能力转化为可投入生产的系统。
他在演讲开头介绍，自己在 OpenAI 伦敦办公室工作，主要负责构建自主代理的执行环境，以及解决更高抽象层级的业务工作流。后面谈到工具接入时，他还举了自己参与的硬件验证场景，包括编译设计、调用模拟器和检查结果。所以他讲得比较多的，是环境怎么准备、工具怎么接入，以及任务具体怎么执行。
原演讲是 《Agentic Coding & Frontier Development》，由 Plain Concepts 发布，全长 47 分 36 秒，强烈建议观看原视频。。
从补全代码到委托完整任务
00:22—06:18
meta-SWE 听起来像一个新概念，但它提出的问题可以从熟悉的开发流程理解。过去，工程师接到需求后，需要阅读项目、确定修改范围、写代码、执行测试，再根据反馈调整实现。AI 最初只参与其中很小的一段，后来逐渐接手更长的执行过程。
Velasco 用 Copilot、Cursor 和 Codex 给这段演进命名。这些名称代表他划分的交互模式，并非对各产品能力的严格分类。对应视频
Copilot 让代码写得更快，但工作流程基本没变
在他划分的 2021—2022 年阶段，AI 主要根据 IDE 中已打开文件的上下文，预测接下来可能需要的代码。整个任务还是由开发者负责，需求怎么拆分、类和方法怎么组织、应该修改哪些文件，都需要人来判断。
这解释了为什么“补全很好用”和“整个项目交付明显加快”未必是同一件事。补全减少了输入和部分机械修改的时间，但需求理解、架构判断、调试和验收仍然占据开发周期。工具改善了一个环节，流程本身没有随之重构。
到了 Cursor 阶段，开发者开始和 AI 反复协作
第二阶段大约从 2023 年开始。IDE 中增加了聊天面板，开发者可以向 AI 描述问题、要求修改，并围绕用户故事或问题单持续对话。AI 能承担的工作从补全代码扩大到一组有关联的修改。
背后的另一项变化是上下文收集。只读取当前文件，很难理解一个跨模块任务；代码检索、代码图谱和语法解析等方法，使工具能够找到更多相关符号和依赖。任务范围扩大，依赖的是模型能力与上下文获取能力共同进步。
不过，日常工作往往还是开发者交代任务，AI 执行，开发者审查，然后再要求它修改。模型越强，这个循环可能越短，但人仍然在频繁决定下一步。
Codex 阶段开始把“接下来怎么做”也交给代理
到了第三阶段，委托的单位变成完整任务。代理接收目标后，自行寻找上下文、规划修改、调用工具，并依据执行结果继续推进。Velasco 将其称为 Codex 阶段，同时明确提到，Anthropic 的 Claude Code 对这一阶段起到了先行作用。
从他的界面演示里，也能看到这种变化。开发者主要在代理面板里分配任务、检查进度和评估结果，开发过程也就越来越围绕代理展开。代码编辑器仍然存在，但人不再需要亲自驱动每一个中间步骤。
中文整理 PPT 用“不到 5%”“约 20%”“约 90%”帮助呈现这种变化。它们涉及不同口径的生产力提升或代理工作占比，属于演讲语境中的估计，不能作为可横向比较的实验结果。我觉得更值得关注的是，代理接手的范围变大了，从生成下一段代码，扩展到了负责一个任务的执行过程。
完整任务委托，先要让仓库可被理解
06:18—09:17
代理接手任务，并不意味着它自动获得了项目成员积累的知识。一个团队可能默认知道测试在哪里、哪些模块不能直接依赖、旧接口为什么没有删除，但仓库本身未必清楚表达这些信息。
要把完整任务交给代理，先得做好仓库代理化，也就是准备好它能读取的上下文、约束和执行入口。Velasco 提到的机制包括 AGENTS.md、Skills、Hooks 和 MCP。它们分别参与项目说明、任务方法封装、执行节点处理，以及外部信息与工具接入。对应视频
仓库代理化之后，任务规范可以直接交给代理。代理依据规范修改代码，再通过测试等明确反馈检查结果，失败后继续修正。开发者的工作随之转向任务方向、验收标准和质量取舍。
这里最容易忽略的是反馈的质量。代理能连续执行很多步，只说明它具备持续推进的能力；测试和约束是否准确，才决定这种推进能否接近目标。如果验收条件缺失，代理可能把“命令执行成功”当成“需求已经实现”。
*图 1 仓库知识的组织方式。原视频 [08:33]
在仓库目录示例中，AGENTS.md 提供入口，进一步指向架构文档、设计记录、执行计划和产品规范。架构说明回答模块边界与职责问题，执行计划记录待推进的工作，产品规范解释行为要求。代理通过这些文件获取项目知识，避免每次从一段临时对话重新建立理解。
AGENTS.md 官方说明也将这类文件定位为面向代理的项目指导，典型内容包括构建步骤、测试方法与代码约定。它的价值在于给上下文一个稳定入口。
Velasco 将这套仓库知识称为人类意图与代理执行之间的“持久化接口”。我觉得这个说法比较具体。需求、约束或架构变了，对应的说明也得跟着维护。如果说明已经过时，代理就可能很认真地执行错误规则。
从单次对话，走向可持续的任务编排
09:17—11:49
仓库准备好后，代理才能在较少临时解释的情况下接收任务。Velasco 描述的下一步包括任务分发、隔离执行、结果优化，以及依据执行轨迹反过来改进运行环境。对应视频
多个代理可以在不同工作树中并行修改代码，减少彼此对工作目录的干扰。每个代理依据测试等反馈修正自己的结果。执行完成后，还可以回头看看为什么有些地方反复失败。是实现出了问题，还是仓库里的说明本身有矛盾，或者漏了必要的信息？
这实际上形成了两个改进过程。一个过程针对当前任务，让代码满足验收条件；另一个过程针对执行环境，让后续任务少走重复的弯路。例如，代理发现 AGENTS.md 与架构文档对同一模块给出了不同约束，就应该把这个冲突留下来处理，而不能只在本次对话中临时绕过。
图 2 代理执行工作流
Symphony 将任务分发进一步接入问题跟踪系统。他演示的是一个简单的 Todo 应用。开发者在 Linear 中创建添加 badges 的问题单，代理就会领取任务，将状态移到 In Progress，随后写代码、执行测试，完成后再更新状态。
这里发生的变化，是问题单开始驱动执行。开发者可以通过工作项组织任务，通过状态观察进度，而不必在每个聊天窗口里重复启动相似流程。
Symphony 还有一个值得注意的地方，项目通过 SPEC.md 描述系统，开发者可以根据这份规范实现自己的版本。公开规范描述的基本职责包括读取问题跟踪系统、为任务创建独立工作区和运行代理会话。
我的理解是，这种编排方式把“持续盯住代理”的责任部分转移给了系统。但任务状态仍然需要与实际产物绑定。问题单变成 Done，应当能够对应到代码变更、检查结果或其他验收证据，否则只是自动化了一次状态更新。
软件写完了？业务任务才真正开始！
11:49—16:40
Symphony 解决的还是软件开发自动化。再往下想，企业开发软件，是为了让人用它完成具体的业务工作。代理既然能够操作开发工具，是否也能操作这些业务工具？对应视频
薪资管理软件最终服务于发放薪资，人力资源软件服务于员工入职。CRM 保存了客户和销售数据，但业务人员真正需要的，可能是一份解释亚太地区销售下滑原因、并给出可采取措施的报告。
这样的报告通常无法通过一次工具调用完成。按照 Velasco 举的例子，需要先查找相关文档，再访问 CRM，导出 CSV，用 Python 和 pandas 分析数据，必要时还要继续查询数据仓库。最终交付的是业务结果，中间可能跨越多个系统和数据来源。
他把这一步称为“Phase 3.5”，代理开始接手更高层级的业务工作流。软件开发只是其中一种场景；统一的难题是如何理解目标、取得上下文，并协调多个工具完成一系列有关联的操作。
要让这种委托可行，代理必须在较长时间里保持目标和判断的一致性。Velasco 将当年 2 月 5 日的模型发布视为一个重要节点，但他更看重的是模型能持续工作多久。模型需要遇到问题后继续尝试，也需要在后续步骤中遵循前面已经做出的决策。
单个 API 重构与整个代码库重构的区别，正好说明这一点。后者包含大量局部修改，但它们不能各自独立成立、放在一起却互相矛盾。较早做出的接口选择，会约束后面的实现；修改数量增加后，代理仍然需要维持一致的设计。
原字幕在这里用“大约 200 次重构”举例，中文 PPT 将其概括成涉及 200 个文件的代码库任务。更准确的理解是多步骤、大范围修改，而非一个经过公开测量的固定规模基准。同样，持续数天、数周的运行在演讲中带有对后续能力的展望，不能直接当成任意任务都能稳定达成的时长。
运行环境怎样连接模型与业务系统
16:40—21:14
长时程任务带来一个具体的架构问题。业务流程在一侧，数据和工具在另一侧，模型需要一个能够组织执行的环境，才能把它们连接起来。对应视频
中文 PPT 第 12 页把这层关系画得比较清楚。业务流程定义目标，Agent Harness 组织执行，MCP 等接口负责访问工具和数据。这里的 harness 可以理解为代理运行环境，它承担基础执行循环、工具调用和上下文管理。
单看执行循环，其实就是判断还要不要调用工具，调用后读结果，再决定下一步，直到能够提交任务结果。真正困难的是，这个循环可能运行很多轮，涉及失败处理、上下文压缩和执行权限。业务开发者如果每次都从头实现这些机制，成本会很高。
Velasco 接着介绍 Codex 的运行环境与界面之间的分离。演讲中的架构图展示了桌面应用、终端界面、Web 运行界面及编辑器集成如何接入 App Server。不同入口可以复用底层执行能力。
图 3 Codex SDK 与代理执行界面的演示画面。相关讲解位于原视频 18:05—21:14。
随后的 Python 示例展示了怎么从程序里调用代理。代码可以提交任务，传入执行权限等配置，让代理使用同一套运行环境工作。他还展示了一个由代理生成、可以在终端运行的 Snake 小游戏。
小游戏本身很轻，但演示的意义在于调用位置发生了变化。代理不再只能等人在聊天框中输入任务，也可以成为业务程序主动调用的一项执行能力。当一个 Python 后端能够把目标和上下文交给代理时，前面提到的跨系统业务流程就有了接入位置。
这样分工就比较清楚了，运行环境处理代理执行的基础机制，业务系统提供目标、数据、权限和验收条件。至于整个流程能不能可靠运行，还得看这些部分能否配合好。
Skills、Hooks、MCP 与记忆分别解决什么
21:14—27:48
有了运行环境，仍然需要把业务知识和工具接入其中。这一段容易被一串名词掩盖，但它们各自回应的是不同问题。对应视频
Skills 让任务方法和资源按需加载
如果把所有任务说明一次性塞进上下文，代理还没开始执行，就要处理大量无关内容。Skills 可以先让模型知道有哪些能力，等当前任务需要时，再加载相关的完整说明。这就是演讲中提到的渐进式披露（progressive disclosure）。
因此，Skill 的价值不只在于把一段提示词保存成文件。它还可以打包脚本、参考资料和其他任务资源，让代理在需要时获取一组相互配合的材料。
同一个项目可能有前端开发、数据质量检查和客户报告等多种任务。它们共享部分项目上下文，但不必在每次执行时都加载彼此的详细步骤。是否需要某项能力，应当由当前任务决定。
Hooks 在指定的执行节点触发操作
Hooks 则解决“什么时候自动做一件事”的问题。演讲举出的节点包括任务开始、调用工具前后，以及执行结束。在这些时点，可以运行确定的脚本，完成相应处理。
这与单纯写一句“记得在结束后整理经验”有所不同。Hook 把触发时机固定在执行机制里。后面的经验提取方法就是这样，任务结束后自动分析执行轨迹。
记忆可以减少重复探索
代理第一次执行任务时，可能试错后才发现必须先建立 Python 虚拟环境，或者某种方法在项目中不可用。如果把这些经验保存下来，下一次执行就有机会跳过同样的探索。
Velasco 特别强调了这里的效率价值。没有记忆，代理也许最终仍能完成任务，但会重复消耗时间和 Token。记忆的意义，是让已经付出的探索成本能够服务于后续任务。
MCP 接入工具，插件把相关能力组合起来
MCP 在这一体系中负责工具和数据接入。以 Velasco 自己的硬件验证工作为例，修改微架构后，还需要编译设计、调用模拟器并读取结果。代理能否参与这套流程，取决于这些专业工具是否通过合适接口暴露给它。
这种场景也说明，代理工程并不局限于常见的办公工具。不同领域有各自的系统、数据格式和执行条件，接入工作需要理解具体业务。
相关 Skills、连接器和 MCP 能力还可以打包成插件，方便别人找到并复用。演讲中的数据分析插件示例同时连接消息、文档和数据平台，并提供数据质量分析、仪表盘生成、业务背景查询等任务方法。单个接口提供访问能力，组合后的插件才更接近一项完整的工作能力。
这些基础能力准备好后，业务型 Skills 的含义就更清楚了。用户真正想完成的可能是回应一份 RFP、处理一次客户升级工单，或者完成销售到交付的交接。“写一个前端页面”是实现层面的任务，而这些业务目标往往需要跨越多个工具和步骤。
但 Skills 开始承担完整业务操作之后，怎么组织、检查和维护它们，就成了接下来要处理的问题。
用理赔流程解释 Skill 编排
29:30—35:37
第一个案例是一家汽车保险公司。风暴之后，公司面对 18,000 件理赔申请，需要进行欺诈分流、支付授权等处理。各环节已经封装为独立 Skill，但单个环节可执行，并不代表整条流程已经成立。对应视频
步骤之间有依赖。如果某个申请需要进一步调查，就不能直接沿用正常支付路径。不同输入可能经过不同分支，前一步生成的材料还要交给后一步使用。问题因此从“能否执行一个 Skill”变成“谁来组织这些 Skills”。
Velasco 最初使用轻量级 DAG 框架，以代码编排调用。随着模型指令遵循能力改善，他开始尝试把编排逻辑本身写成 Skill，在里面说明可以调用哪些子 Skills、执行顺序和起止状态是什么、有哪些依赖，以及步骤之间怎么传递产物。
在演示的编排说明中，代理需要知道输入应当是什么、到仓库哪里寻找上下文、有哪些 Skills 可供调度，以及什么条件决定下一步。路由条件要写清楚，正常输入应该走哪条路径，某一步失败后又该转向哪里，都需要有依据。
这里的 18,000 件是案例设定。现场展示使用的是简化的 CSV 示例数据，讲者随后展示了几个样例的执行轨迹，并让代理生成 Mermaid 图解释各理赔申请经过的路径。不能将这段演示理解为现场完成了 18,000 件真实理赔。
看这几个样例，就更容易理解它怎么工作了。输入决定分支，子 Skill 处理具体步骤，执行轨迹记录实际发生了什么。编排说明与最终轨迹能够相互对照，才有机会检查执行是否符合预期。
Velasco 表示，他在自己的实验中观察到了很强的指令遵循效果，因此减少了维护专门调度代码的需要。这是他的实践经验，并不是对任何自然语言编排系统都适用的保证。演讲使用 DAG 描述依赖关系，同时也提到循环和终止状态；在实际实现中，仍应清楚定义这些控制语义。
对这个模式，我最看重的是业务流程可以被直接阅读和审查。与此同时，支付等具有实际副作用的操作，仍然需要由执行系统落实权限、输入校验和重复执行控制。把流程写进 Markdown，改变了流程的表达方式，业务责任依然存在。
Skill 也需要输入输出契约和公共组件
35:37—39:06
编排解决了“多个步骤怎么连接”，接下来要处理“每个步骤怎样可靠地工作”。如果一个子 Skill 的输入要求不明确，或者输出结构经常变化，依赖它的后续步骤就很难稳定运行。对应视频
Velasco 开始像维护软件组件一样维护 Skills，把它们放进版本管理，定义稳定结构，并补上输入契约、输出契约和执行中的检查关口。他使用 Rules 与 Gates 区分要求和验证。
| 组成部分 | 要回答的问题 |
|---|---|
| 输入契约 | 开始执行前，应该得到哪些数据和上下文？ |
| Rules | 执行时必须遵守哪些要求？ |
| Gates | 用什么证据检查这些要求是否已经满足？ |
| 输出契约 | 下一个步骤能够接收到怎样的结果？ |
规则告诉代理应当做什么，检查关口要求它证明自己做到了。例如，要求输出包含必要信息属于规则，逐项核对这些信息是否存在则属于验证。这里的例子只是对机制的解释；真正的检查项目仍然要来自业务要求。
图 4 Skill 的规则、检查关口与输入输出契约。原视频 36:49
这套结构用得多了，上下文说明、规则和检查关口就开始重复，维护起来也有些麻烦。相同内容分散在许多文件里，一次修改可能需要同步多个位置，也容易出现不同版本互相冲突。
Velasco 的处理方式和普通软件开发很像，把重复部分提取成公共资源，再用模板组装。他展示了 Jinja 模板，将可复用的上下文、Rules 和 Gates 组合成最终 Skill，然后交给代理执行。
这一变化使 Skill 从手工复制的长文档，逐渐变成可以组合、版本化和维护的任务组件。模板本身并不让模型更准确，但它有助于控制输入说明的一致性，避免相同规则在多个文件中逐渐分化。
再回头看前面的编排案例，编排器需要调用子 Skills，子 Skills 就得有稳定的输入输出边界。边界不清楚时，编排器就必须在运行过程中猜测每一步会产出什么，整个流程的维护难度也会随之增加。
Best-of-N，把候选生成与最终选择分开
39:06—42:26
即使 Skill 结构一致，LLM 的输出仍然存在随机性。同一个任务执行多次，可能得到不同计划或结果。前面的契约和检查解决的是遵循要求的问题，这一段则开始讨论候选结果之间的差异。对应视频
演示使用了 B2B 续约相关场景。Velasco 让多个子代理在不同工作树中处理同一个问题，各自产生输出，再通过仲裁步骤读取这些结果并选择最终方案。他把这种模式称为 Best-of-N。
图 5 并行生成与结果择优
它与把一个大任务分成几个子任务不同。任务拆分时，各代理分别负责不同部分，最后需要组合产物；Best-of-N 中，各代理处理的是同一个问题，最后需要比较候选结果。演讲现场展示了三个代理同时工作，随后由仲裁逻辑挑选输出。
所以生成候选和评估候选都很重要。只把并发数量加上去，评估的问题还是没有解决。
我的理解是，如果最终评估只能依据文字是否流畅、解释是否完整，选出的可能只是表达更好的方案。对于能够客观检查的任务，应尽量把检查结果交给仲裁过程；对于难以直接验证的业务判断，则需要明确评价依据，并保留人工判断的位置。
候选之间是否真正存在差异也很重要。如果所有代理读取了同一份错误说明，它们可能以不同措辞得出同样有问题的结论。Best-of-N 提供了比较空间，不能替代正确的上下文和验收标准。
这一模式还会增加计算成本。Velasco 认为它值得用于高价值工作流，这个限定应当保留。对于简单、容易一次验收的任务，多次并行执行未必划算；对于候选质量差异较大、选错代价较高的任务，额外执行才更有讨论价值。
retrieve-hints，让执行经验进入下一次任务
42:26—44:21
前面的模式仍然主要优化当前任务。下一步是让本次执行产生的经验能够帮助下一次任务，减少重复探索。对应视频
Velasco 希望自己能够控制提取哪些经验，因此设置了一个任务结束后触发的 Hook。它读取 Codex 的执行轨迹，提取指定领域中的经验与教训，并写入 Markdown 文件。
他的领域例子来自半导体和硬件验证，包括 CPU 启动、内存控制器等主题。经验按照相关功能区域组织，方便后续任务找到对应内容。需要保存的不是整段聊天记录，而是对以后执行有帮助的发现。
新的任务到来时，retrieve-hints 根据任务意图检索相关经验。讲者举出取回若干条最相关提示的做法，再将这些提示加入上下文。这样既能复用历史经验，也不必把全部历史记录重新加载一遍。
这里的“学习”发生在外部记忆与上下文层面。它不等于模型参数经过了训练，而是代理下一次执行时，能读到上一次整理出的有效信息。
比如，某个环境必须先完成特定初始化才能运行检查，第一次执行可能需要试错才能发现。记录这条经验后，后续任务可以直接满足前置条件。节省的是探索时间和重复调用成本，而不仅是让回答显得更了解项目。
在这个基础上，我认为还需要考虑经验的适用范围与有效期。旧版本有效的方法未必适用于新版本，一次临时绕过也不应该自动变成永久规则。保存经验时保留产生条件，并允许后续证据修正它，才能避免记忆累积成另一套过时文档。
skill-decomposer，处理逐渐失控的 Skill
44:21—45:49
随着业务场景增多，规则、异常分支和工具调用会不断进入 Skill。最初很清楚的说明，可能逐渐变成一个难以理解的大文件。这是 Velasco 在大量编写 Skills 后遇到的问题。对应视频
他为此设计了 skill-decomposer，让一个 Skill 检查另一个复杂 Skill，再把它重构为一个外观接口和多个最小化、可复用的子 Skills。外观接口保留任务入口，内部步骤则按照职责拆开。
这一方法与前面的模板复用有关，但处理时机不同。模板化适合抽取多个 Skills 之间反复出现的共同结构；分解器则针对已经变得臃肿的单个 Skill，重新梳理职责和内部关系。
拆分是否成功，也不能只看文件变短了没有。如果一个子 Skill 依赖父任务中未说明的背景，单独调用时无法工作，拆分只是把隐含依赖藏进了更多文件。它仍然需要前面讨论的输入输出契约，以及能够检查原有行为是否保留的案例。
这五组方法处理的问题是连着的。编排器组织任务步骤，契约和模板控制组件结构，Best-of-N 比较候选结果，记忆复用执行经验，分解器处理越来越复杂的 Skill。它们都在把已有的软件工程方法应用到代理工作流上。
工程工作扩展到了代码之外
45:49—47:36
演讲结尾，Velasco 展示了自己的《一次性代码宣言》，并引用其中关于“超越代码的工程”（engineering beyond code）的表述。他还展示了一张设想中的《Markdown 架构模式》书籍图片。对应视频
结合前面的案例，这个结尾就有了具体含义。架构设计可能体现在仓库知识的组织方式中，接口设计可能体现在 Skill 的输入输出契约中，流程控制可能体现在编排说明中，质量检查则需要进入 Gates 和验收机制。代码仍然存在，但工程师需要维护的对象明显增加了。
我更愿意把这理解为工程职责的扩展。代码生成成本降低之后，需求是否清楚、工具是否可用、约束是否一致，以及结果是否能够验证，会更加直接地影响交付质量。写得很完整的 Skill，如果依赖错误数据或缺少验收依据，仍然难以产生可靠结果。
对于现有项目，我觉得还是可以先做好仓库准备。让另一个执行者能找到构建入口，理解模块边界，并独立判断一次修改是否符合要求。做好这些以后，再根据真实失败记录引入编排、模板、记忆或并行择优。
判断一套代理工作流是否成熟，还是得看具体任务。需求明确之后，它能不能给出可检查的结果？如果失败了，团队能不能从执行记录里找到原因，让同类问题少发生几次？后半场那些更复杂的方法，都应该服务于这个目标。
笔记附件
下载《meta-SWE · Agentic Coding 技术笔记》PPT（PPTX，约 8.5 MB）
这份 PPT 是我根据演讲整理的笔记，如果使用请标注为雪落为制作者。
来源与配图
- Luis Velasco，Agentic Coding & Frontier Development · CONVEX 26，Plain Concepts 发布，47 分 36 秒。文章顺序与案例依据原演讲、自动生成的西语字幕及中文整理稿，专有名词结合画面与整理 PPT 校对。
- CONVEX 2026 官方讲者页，讲者职务与演讲主题。
- Shift 2026 讲者简介，讲者工作方向。
- AGENTS.md 官方说明，仓库指导文件的用途。
- OpenAI Symphony 规范，任务编排服务的基本职责。
文中讲者的案例与经验判断归于讲者；明确使用“我的理解”“我认为”等表述的段落为本文分析。演讲与原始画面的权利归各自权利人所有。