Codex、Skill、MCP与本地模型：扩展能力而不外包责任¶
这一单元讨论四种容易混为一谈的能力。Codex是与你共同读取、修改和验证项目的工作代理；AGENTS.md把项目长期规则带入每次任务；Skill把一套可重复的方法、参考和脚本组织成可触发工作流；MCP让代理连接外部工具与上下文；本地模型则改变推理或生成发生的位置。它们都不能替你批准镜头、判断许可或决定影片主题。
本页的Codex、Skill和MCP事实依据OpenAI官方文档于2026-09-07核对。界面、配置和可用能力会更新，实际使用前应重新查看官方文档。本地模型部分只讲选择与治理原则，不指定“永远最佳”的模型和参数。
一、先把任务写成可交付问题¶
代理最难处理的不是长任务，而是边界不断移动的任务。“帮我优化项目”没有说明优化对象、允许修改范围、完成证据和禁止动作。更好的任务写法是：“审查第8章是否达到2.6万有效字符；只修改章节和模型适配卡；不生成媒体、不下载权重；运行教材校验、测试和严格构建；报告仍未通过的门槛。”
一个可交付任务包含五项：目标结果、允许范围、已有事实、限制条件、验证方式。目标描述用户拿到什么；范围列出目录或文件；已有事实避免重复探索；限制保护媒体、密钥和历史；验证说明哪些检查构成技术完成。创作接受仍需人看内容，不应被“测试通过”替代。
大任务要按风险和依赖拆分，而不是按文件数量平均切块。先固化幸存版本，再归档远端旧版，随后恢复活动教材、逐章扩写、补工作簿、补进阶篇，最后改全书状态。每部分完成就检查内容、结构和显示，这样错误不会累积到最后才发现。
二、让项目文件承载上下文¶
聊天能帮助思考，却不应成为项目唯一记忆。README说明入口和读者路线；AGENTS.md说明代理在本仓库应遵守的规则；迁移文档记录环境与恢复边界；章节元数据提供结构化事实；提交历史解释每次可恢复变化。重要决定进入合适文件后，换电脑或换会话仍可继续。
根据OpenAI官方文档，Codex会在工作前读取AGENTS.md指导，并按全局、项目根到当前目录形成有优先级的指令链。对学习项目，根规则应短而稳定：活动教材在哪里、归档不可进入导航、使用什么命令检查、哪些媒体状态不能虚构、Windows与AutoDL命令怎样标识。具体章节写作要求放在教材规范，不把整本书复制进代理指令。
目录越深的规则只处理该局部特例，不能与根规则无意冲突。每条规则应解释可观察行为，例如“所有待生成媒体必须显式标注状态”，优于“保持专业”。规则过多会挤占任务上下文，也让真正关键的安全边界被淹没。
官方参考：AGENTS.md说明。
三、先审查，再修改，再独立验证¶
让代理“直接修好”之前，先区分审查与实现。审查阶段只读文件、运行非破坏检查、列出证据和风险；实现阶段按已同意范围修改；验证阶段从不同角度检查结果。一个脚本自己生成文件再报告“成功”，属于同一路径自证，最好再用解析器、测试、严格构建和实际页面查看交叉验证。
差异审查关注四类问题：是否修改了授权范围之外的文件；是否静默覆盖用户已有内容；新文字是否与元数据、案例文件和状态一致；是否把未实机验证写成已完成。提交应按可理解的工作单元组织，例如“一章正文”“十二份工作簿”“进阶篇”，不要把归档、内容改写和环境缓存混成一个巨大提交。
自动测试能检查ID、链接、结构和篇幅；来源检查能发现失效链接；项目验证能暴露缺失资产；网站构建能发现Markdown问题；桌面和手机实看能发现表格、目录和折叠块的阅读问题。几种证据回答不同问题，全部通过也仍不证明影片已经生成。
四、权限边界比能力列表重要¶
代理能够调用工具，不等于每个任务都授权调用。读取文件和查看差异通常风险较低；提交代码仍只影响项目历史；推送、创建PR、发送外部消息、删除远端数据、调用付费生成和公开发布会改变外部状态，需要任务本身明确包含这一步。遇到不清楚的外部影响，应先停下来说明选择。
文件操作也有层级。创建派生网站通常可重新生成；覆盖唯一媒体、清理工作树或重写Git历史难以恢复。安全顺序是先解析确切目标、确认它位于预期目录、保留版本或备份、执行最小变更、再实际读取结果。不要把工作区根目录、用户主目录或未解析变量作为递归删除目标。
密钥、令牌、私人声音和未授权素材不因为代理能读取就应进入上下文或日志。向外部服务发送文件之前，先问该文件是否必要、是否含隐私、服务将怎样处理、能否用去敏样本完成同一诊断。MCP和云模型扩大了能力，也扩大了数据边界。
五、Skill是方法包，不是万能咒语¶
官方文档把Skill描述为包含SKILL.md及可选脚本、参考和资产的目录，用于让ChatGPT或Codex可靠遵循某类任务工作流。Skill可以被明确调用，也可能因为任务与描述匹配而触发。它最适合把已经反复验证的方法固化，例如“短剧资产拆解”“教材来源审计”或“文档渲染与视觉检查”。
Skill描述要写清什么时候使用、什么时候不用。指令说明输入、步骤、决策点、输出和安全边界；参考资料只在需要时加载；脚本处理机械操作；模板保证交付格式一致。不要把几十种无关能力塞进同一个Skill，也不要只写“做得专业”这类无法执行的要求。
创建Skill前，先手工完成流程至少一次，并记录最容易出错的判断。若流程仍依赖大量临场猜测，过早封装只会稳定地重复错误。测试Skill时准备正常、缺失输入、冲突输入和危险请求四类样例，检查它能否正确完成、拒绝或请求必要信息。
Skill版本变化也要审查。新的脚本可能扩大文件或网络权限，新的参考可能过时，新的描述可能导致错误触发。把Skill视为项目依赖：记录来源、版本、许可和适用范围；升级前看差异；对能写文件、访问账号或调用费用的能力做更严格验证。
官方参考：构建Skills。
六、MCP连接的是工具与上下文¶
Model Context Protocol（MCP）让模型访问第三方工具与上下文。OpenAI官方文档列出本地进程式服务器和可通过网络访问的服务器等连接形态，并说明Codex主机可以配置服务器、认证和工具范围。对电影项目，它可能连接文档库、设计工具、浏览器或项目服务，但“已连接”不代表“所有操作都应自动执行”。
先为每个连接写权限表：它能读取什么、能写什么、数据发送到哪里、凭据由谁保管、失败会留下什么、如何撤销。只需要查官方文档时，不应开放项目写权限；只需要读取一个表格时，不应允许删除整个数据库。工具允许列表比“以后可能有用”更安全。
MCP工具返回的内容也不是天然可信。外部网页、文件名和服务数据可能包含错误、过期信息或诱导指令。代理应把它们当数据，用项目规则和用户目标判断，而不是让外部内容改写权限。来源记录至少包含服务、查询时间、返回对象和用于哪个决定；易变化事实在发布前重新核验。
认证信息应由安全配置或授权流程管理，不放进教材、Git和任务提示。连接失败时区分服务器未启动、地址错误、认证失败、权限不足、工具超时和数据格式错误。反复重装通常不是第一步；先读取明确状态和错误，再做最小修复。
官方参考：Codex中的MCP。
七、为微电影设计最小能力栈¶
第一层只有文件与Git：剧本、镜头表、提示、工作簿和验证脚本已经足够完成教材学习。第二层加入只读工具：搜索官方来源、读取媒体元数据、检查链接。第三层才加入写入型工具，例如生成文档、更新表格或调用ComfyUI。第四层涉及外部账号、付费API和发布，必须有预算、权限和回滚计划。
堆叠工具会增加隐性状态。一个失败可能来自代理理解、Skill规则、MCP连接、第三方服务、模型版本或本地环境。能力越多，诊断链越长。每新增一层，都要写出它替代了哪项重复劳动、引入了什么风险、怎样关闭，以及没有它时的手工备用流程。
《回声舱》当前最小栈是Markdown、CSV、Git和本地验证脚本。即使没有任何MCP，也能完成内容与生产计划。若未来连接GitHub，先用于只读比对提交；若连接生成服务，先跑一个低风险镜头；若连接发布平台，保持默认不发布。逐层证明价值，避免为了“自动化全流程”把创作控制交给一串不透明调用。
八、本地模型改变的是部署边界¶
本地模型的优势可能包括数据留在自控环境、可固定权重、可离线重复和避免按次API费用；代价包括硬件、磁盘、下载、依赖、运维、速度和许可证判断。云端服务可能降低部署负担并提供完整管线，却增加上传、队列、价格和接口变化。不存在脱离项目约束的绝对最佳路线。
选择前比较六项：任务是否含敏感素材；目标质量和控制模式；显存、内存、磁盘与时间；总拥有成本；模型与代码许可；能否恢复相同环境。权重“可以下载”不等于允许在所有地区和所有商业场景使用，开源基础模型也不等于复制了在线服务的全部预处理和再生成组件。
不要先下载大型模型再寻找用途。先用模型卡和官方示例核对输入模式、最低硬件、输出规格和许可；估算下载与运行成本；在隔离目录保留校验和与版本；用低风险测试资产跑最小任务；只有结果满足明确需求才进入生产环境。失败时保留日志，不在唯一工作站上无限叠加依赖。
本地服务也需要权限边界。默认只监听本机；若开放到局域网或公网，要有认证、访问控制和日志，并确认不会暴露输入、输出和工作流。关闭界面不一定停止后台服务，任务结束后检查进程、端口和远端计费状态。
九、把代理用于学习，而不是替你跳过学习¶
让Codex解释一个文件时，可以要求它先画出数据流、再指出三处风险、最后设计一个小练习；不要只让它给出“正确答案”。让它修改提示时，要求保留导演意图并列出改变的单一变量；让它审查镜头时，区分可观察事实和推断。你越能提出判断标准，代理越能成为外部化思考工具。
反向讲解是很好的检验：读完代理生成的说明后，关掉页面，用自己的话解释为什么任务受理不等于完成、为什么Skill不等于工具权限、为什么MCP返回内容仍要核验。解释不出来就回到最小例子，不让更多术语遮盖理解缺口。
代理输出也可能过度自信。要求它引用实际文件、官方来源和检查结果；对时间敏感事实现场核验；对法律、许可和费用保留人工决定。若它说“全部完成”，检查是否真的有输出文件、测试、页面和外部状态证据。语言流畅不是可靠性的证据。
十、《回声舱》的扩展练习¶
练习一：为“检查八份视频提示与镜头模式一致”写一个任务简报，限定只读，列出输入、输出、错误和警告。再判断这项流程应留在项目脚本还是封装为Skill。只在多个项目反复使用且规则稳定时，Skill才有维护价值。
练习二：假设接入一个云端媒体库MCP。写权限表，默认只允许列出和读取指定项目文件；下载必须落在临时目录；删除、共享和公开发布保持禁止。为认证失败、文件不存在和返回内容与清单冲突各写一个停止条件。
练习三：比较H3在线/API、本地H3-Base和混合路线。不要只比单次价格；加入硬件、时间、数据上传、开放组件边界、许可和恢复成本。然后为SH-001选最低风险验证路线，说明这一选择只是当前实验决定，不是全书永久推荐。
练习四：让代理生成一次变更摘要，再由你独立查看Git差异。检查它是否漏报删除、状态升级或外部链接变化。只有差异与摘要一致、测试覆盖相关风险、页面实看正常，才提交这个工作单元。
十一、故障与退出策略¶
代理误解范围时，先停止继续修改，保存差异，明确保留和撤销目标；不要用清理整个工作树解决局部问题。Skill错误触发时，检查描述与边界，先禁用或缩小范围。MCP失败时，记录连接方式、认证状态和最小工具调用，不把密钥粘贴进聊天。模型服务失败时，区分环境、任务、输出和内容层。
每种扩展都要能关闭：没有Skill仍可按文档手工完成；没有MCP仍可导出文件人工交换；没有本地模型仍可保留不依赖模型的镜头规格；没有代理仍能从README、项目规则和任务清单继续。备用流程使项目不会被单一工具锁死。
本篇检查表¶
- 任务是否写明结果、范围、事实、限制和验证。
- 重要上下文是否进入项目文件，而不是只留在聊天。
AGENTS.md是否短、稳定、可观察，并与目录规则一致。- 审查、实现、测试、视觉检查和创作批准是否分开。
- 外部写入、付费调用、推送和发布是否有明确授权。
- Skill是否封装已验证方法，并有触发与禁用边界。
- MCP是否遵循最小权限，外部返回是否仍当作待核验数据。
- 凭据、私人素材和未授权媒体是否不进入Git或日志。
- 本地模型选择是否考虑硬件、总成本、许可和恢复。
- 每一层扩展是否有关闭办法和手工备用流程。