一个独立播客团队维护节目网页和章节生成脚本。剪辑师发现，同一段访谈在音频剪掉开场后，网页章节仍指向旧时间。团队希望让 Codex 进入项目处理这类任务，同时保留能交接的上下文、知识记录和验证方式。用虚构访谈与一份本地演示页，先完成一次章节偏移修复，再判断哪些工作适合批处理或拆分。这里不需要假设存在一个聊天模式与智能体模式之间的神奇开关，关键是当前工具、资料和任务授权是否足以执行。
项目现场由可读取的材料组成
开始前保存仓库位置、当前分支、未提交差异、运行环境和演示页启动方式。确认音频与章节清单的对应版本，记录剪掉开场的时长。让剪辑师说明规则：章节时间相对于最终交付音频，不得小于零，也不能超过音频长度。准备三条虚构章节和一份带时长的清单，手工算出预期位置。不要把真实未公开访谈直接用于练习或发送到不必要的外部服务。
给 Codex 一张任务卡，写明目标、输入版本、允许目录、预期产物与验收条件。先要求找到从章节源文件到生成脚本再到页面的路径，并说明要读取哪些材料。能运行本地工具的环境可以检查文件和执行测试；不可用的工具则要列为限制。回复里说「理解项目」不是证据，实际读过的入口、当前差异和可重跑命令才让维护者判断它是否进入了正确现场。
按现有项目惯例组织资料。README 说明启动入口，AGENTS.md 保存长期工作约定，任务记录保存这次的状态与验证。其他规划和日志文件都是可以选择的组织方式，可参考 OpenAI 的工作流示例，无需为了配置完整而创建所有文件。把本次关键背景入口写到任务中，不能假设任意笔记都会自动被读取。
先形成可复核计划，再执行有限改动
把工作拆成定位偏差、修复转换、核对产物和交接四个结果。定位时比较原章节、剪辑说明、生成中间值和网页最终时间。若源文件已是最终音频时间，生成器又减了一遍开场，应保留这一因果对照；如果源文件还未更新，则先确认由哪个步骤负责转换。不要在未明确责任时同时改源数据与生成器，让两次错误互相抵消。
先用固定小样在旧实现上捕捉偏差，再修改负责转换的位置。断言前三个章节的时间、排序与边界，并检查开场前的记录按约定处理。修复后生成到独立产物目录，比较原始输入没有被覆盖。若异常路径被吞掉导致仍输出成功状态，补一个明确失败样本。任务卡中的命令必须实际运行才记为通过，缺少依赖或服务不可用时保留原因与补测方式。
页面检查可使用 Webapp Testing。已核对条目支持 Python 与 Playwright 操作运行中的本地应用，并产出脚本、截图和浏览器日志。把它放在章节产物生成后的页面验收，提供本地站启动方式、虚构章节与预期时间，先观察页面控件再操作。浏览器依赖、文件与目标范围先核对。该步骤不负责剪辑音频，也不替代对真实声音内容的人工核听。
知识库记录原因、证据与适用范围
完成后将经验写成短条目：什么症状、输入版本、原因、修复责任边界、检测样本和未覆盖项。为条目加上章节时间、生成器或交付音频等任务相关索引，并指向实际代码与验证记录。只保存有依据的长期事实，未确认推断单列。它可以放在仓库文档或团队知识工具中，但必须有明确维护者与可访问入口，不能因叫知识库就自动保证检索质量。
下一次遇到章节问题时，让助手先列可能相关条目，再打开原记录核对当前版本。旧条目针对减开场时长，新问题可能是插入广告改变时间轴，不能直接套同一个修复。记录适用条件、反例和替代路径，比堆积聊天全文更容易辨别差异。外部笔记暂不可访问时，说明缺口，用已有确认材料继续独立部分，不能声称已经检索过不可读的历史。
复盘记录要能由他人验证。请另一位编辑只看条目找到修复位置、生成一份小样并解释为什么没有重复偏移。找不到输入或输出对应关系时补运行编号与版本。知识条目过期时保留历史入口并更新权威说明，避免多个副本互相矛盾。真实账号、访问凭据和未获授权的访谈内容不进入可共享练习记录。
效率技巧围绕输入输出与依赖选择
批量检查适合彼此独立且格式一致的输入。先用一集试跑，确认错误能归到具体章节文件，再扩大到多集，并给每个结果保留编号、源版本和状态。一个文件失败不应被其他成功掩盖，重试只针对已定位原因或可解释的临时故障。保持原始资料不变，最后汇总成功、失败、跳过和待人工核听部分。批量输出还需要抽查，不能只看文件数量。
若当前环境支持且任务授权允许拆分，可以把独立资料核对分给不同工作单元，但共享代码由明确整合者处理。每项提供输入版本、范围和交付格式。需要因果判断后才能修改的步骤保持顺序，不能为了并行先让多个单元同时改生成器。评估是否值得拆分时记录总耗时、合并冲突、重复调用和人工复核。额外协调可能增加成本，一项小修复用单一流程也能完成。
需要新能力时先检查是否已有 SkillPI Skill Finder。没有时阅读官方仓库说明，按当前宿主支持方式启用。用章节生成、页面核对或技术文档复核等具体缺口搜索，打开候选来源、版本、依赖与权限，再用相同小样比较。不要把另一宿主的任务管理工具视为所有 Codex 环境的必需品，也不能承诺任意技能跨宿主安装方式相同。
交付包让下一位编辑能接着做
最终记录带上分支与差异、章节规则、输入版本、生成产物、检查结果和未覆盖项。把已经执行的动作与建议分开，页面生成、文件导出和节目发布也是不同状态。请接手者重新生成一条章节并打开演示页，核对显示与预期时间。若他必须阅读整个会话才能判断完成条件，就补足缺少的任务信息。
下一期复用时先更新音频版本与编辑变化，回放同一个已标注小样，再处理新资料。只沉淀对再次执行有帮助的步骤，移除过时入口。技能目录增长后按实际缺口定期比较新候选，验证用途与结果后再改关联。项目搭档的价值体现在正确产物、可恢复状态和交接质量，不能由安装数量或固定学习天数推出。
常见问题
开始前一定要扫描整个仓库吗？
先围绕任务找到入口和相关调用链，缺什么再读取什么。完整扫描可能带来无关材料；范围有限也要明确缺口。目标是足够证据，而不是文件阅读数量。
准备知识库就能自动检索所有历史吗？
需要可用的访问工具、明确入口和实际检索。给条目结构、版本与来源，用一个已知问题检验命中和适用性。未访问到的记录不能算已核对。
必须安装委派技能才能执行项目任务吗？
不是这个案例的前提。先看当前宿主与工具能做什么，再根据瓶颈选方法。独立任务是否拆分要有授权、清楚输入和整合责任，小任务不必为委派而委派。
效率方法能直接换项目使用吗？
任务卡和证据交接的思路可复用，具体命令、数据格式与权限需要重新确认。用目标项目的小样验证，不把这次成功当成通用兼容证明。
资料缺失时应该停在哪里？
先完成不依赖缺失内容的定位或检查，写清不能判断的条件和需要的最小信息。若音频与章节版本不明，就不能确认最终时间正确；保留现有产物与待办再交接。