一个业余棋赛组织者维护成绩网页，准备把「缺席」与「尚未录入」两种状态分开显示。用 Codex 做过几次修改后，他发现每次都要重新解释目录和计分规则，旧会话的结论有时又与当前分支不一致。进阶配置可以从三个可检查的产物开始：项目工作约定、可定位的背景记录，以及带验证结果的任务交接。以下用虚构棋手和本地练习站完成一次小改动，不以七天或安装数量衡量熟练程度。
行为规则写成可执行的项目约定
先保存项目位置、分支、当前差异、启动命令和正常样本。让维护者确认两种状态的业务规则，缺席是已确认没有参加比赛，尚未录入意味着结果仍未知。界面文案与导出值分别说明，避免为了显示清楚而改变外部消费方的字段。给本次任务限定文件和验收：两种状态可区分，正常比分不变，导出仍可被旧工具读取。配置工作的价值，要由这样具体的结果验证。
在项目约定中记录稳定事实与约束，例如相关模块入口、常用检查、生成文件处理和测试数据要求。AGENTS.md 可用于持久的仓库工作约定；项目阶段记录与执行日志则保存这次任务的进度，这种分工可参考 OpenAI 的工作流示例。这些其他文件是项目约定，不因创建了文件就保证每个会话会自动读取。给当前任务明确入口，并要求助手先报告它依据的材料与适用范围。
把规则写成能观察的要求。比如「改动结果状态后运行项目已有状态测试，并核对两个虚构棋手的页面显示」，比「始终保证高质量」更容易检查。只记录长期有用的规则，阶段性探索留在任务记录。新会话从正确工作目录开始，先核对已读规则、当前源码和差异。若实际行为与约定不同，找出是规则未加载、作用范围不符、说明过期还是任务信息缺失，再修改对应位置。
同时使用其他编码宿主时，分别查它们的指令加载机制，不把 CLAUDE.md 与 AGENTS.md 当作自动同步的两份文件。可以共享业务事实与测试要求，但保留各宿主需要的入口和格式。更新规则后用相同小样分别演练。规则变多时检查冲突和重复，保留必要边界；不要把每次偶然失败都追加成全局禁令，让正常工作越来越难解释。
共享背景要能找到来源和当前版本
为成绩页准备一份背景卡，记录状态含义、数据流、相关文件和已确认的消费方。每项重要事实指向当前代码、业务说明或明确负责人的确认。把未解决问题与已经确定的规则分开，例如历史数据中的空值究竟代表未知还是缺席，尚未确认就保留为问题。背景材料可以存在团队文档或笔记工具里，但当前会话要能实际访问，并知道哪一份是权威版本。
不要把文件名叫作记忆就认为系统必然会记住它。给新任务附上背景入口，要求助手打开相关段落并对照当前分支。外部笔记不可用时，先说明缺口，使用仓库内经过确认的摘要继续可独立工作。保存摘要更新时间与来源，避免旧笔记覆盖新实现。含真实棋手联系方式或账号资料的内容不进入演练包；共享材料只保留任务所需信息。
交接时记录目标、已证实事实、修改文件、检查命令、结果与下一步。比如状态映射已调整，但旧导出消费方尚未复验，就明确写成待完成。新会话先看工作区，确认记录中的差异确实存在，再重复一条关键检查。若日志说已经修好而当前分支没有改动，先查分支与版本，不能直接继续宣布完成。共享背景帮助定位，实际文件与证据决定当前状态。
定期清理过时背景，保留变更原因和历史入口，而不是多处复制相同规则。计分规则更新后，一次修改权威说明，并标记受影响的测试与页面。让一名未参与任务的人用入口回答「这两个状态为何不同、怎么验证」，从他的疑问补充缺少材料。维护成本也要记录，避免节省了会话解释，却制造大量互相冲突的文档。
实操沉淀从一份任务卡开始
任务卡给出触发、预期结果、允许路径、输入版本和验证方法。先让 Codex 找到结果解析到页面显示的链路，再提出有限改动。准备两个边界记录与一个正常比分，在旧实现上观察状态混淆，再改实际负责映射的位置。运行既有检查，核对页面与导出。对无法运行的环境或依赖写明原因，不把计划中的命令记成已执行。
页面复验可用 Webapp Testing。已核对条目描述 Python 与 Playwright 操作运行中的本地应用，产出脚本、截图和浏览器日志。它放在结果状态改动后的界面验收，输入是练习站启动方式、三条虚构记录与预期文字。先准备浏览器依赖、确认执行范围，观察渲染控件后再操作。导出兼容仍用原消费方或契约样本单独核对。
完成后只沉淀真正会再次用到的经验。记录混淆发生的入口、根因、修复边界、能检测它的样本和尚存限制。持续的项目事实归入规则或背景，重复操作可整理成技能，单次进度留在任务日志。不要为了复盘把整段聊天复制进长期说明。让下一位维护者按记录复跑一条状态检查，确认经验可以转化为行动。
若需要技能辅助发现，先检查是否已有 SkillPI Skill Finder。没有时阅读官方仓库说明，按当前宿主支持方式启用，再按具体能力缺口搜索候选。候选必须能核对来源、版本、依赖和产物，用同一小样试验。专用于另一宿主配置的技能不能仅因名字含专家就用来指导 Codex。找到合适方法后，记录它用于哪一步以及没有覆盖的边界。
当前 OpenAI 技能文档 说明技能有名称、描述和完整指令，并支持显式选择与按任务匹配。配置后分别验证发现、调用和结果。技能清单与指令会占用上下文，安装很多项也需要检查描述、命名和有效范围，不能承诺数量增加完全没有开销。把稳定任务方法写清触发与不适用条件，再用正反样本测试是否误用。
常见问题
配置后每次都能记住所有历史吗？
不要作这种假设。给任务明确材料入口并检查实际访问，摘要保持可回到证据的链接。会话记录、项目文件和宿主功能承担的作用不同，当前版本支持什么要分别确认。
规则写得很细，反而影响工作怎么办？
找出重复、过时和互相冲突的条目，用同一任务比较精简前后的行为。长期约定保存必要边界，具体实现让源码与任务卡决定。不要为获得灵活性删除真实权限限制。
可以自动更新经验日志吗？
在任务明确包含更新记录时，让助手提出有证据的条目并写入约定位置，再核对差异。指定维护人和清理方式，避免把推测、凭据或一次性错误写成长期事实。
换工具是否能直接用同一份配置？
可复用业务规则，但各宿主的加载位置、工具接口和扩展字段需要核对。分别用同一任务验收，不把一个宿主成功推及所有环境。
怎样判断进阶配置值得保留？
观察重复解释、误修、返工和交接时间是否减少，同时检查结果是否正确。用同样输入与完成条件对照，保留有帮助的约定，调整无法证明作用的复杂配置。