一家小型展馆用内部网页导入藏品清单。维护者让 Claude Code 修复 CSV 导入时空白行计入总数的问题，但每次都要解释目录、粘贴整份日志，最后还要追问到底跑了哪些测试。改善效率先看一项改动从接单到复核用了多少时间，再分别改进项目配置、上下文输入和交付方法。下面用虚构藏品与练习分支演示，目标是让同一故障更容易定位和验收。
用可比较的任务建立基线
保存一份含三条有效藏品、一条空白行和一条缺编号记录的 CSV。先由业务负责人确认规则：空白行跳过，缺编号记录报告错误，有效记录数应是三。记录原版页面显示的数量与错误信息，保留构建号、导入参数和测试数据版本。用当前工作方式完成一次定位，记下查找文件、补充说明、运行检查、等待和返工分别发生在哪里。完成时间必须包含人工纠错与复核，否则只是把工作挪给了下一位维护者。
比较前固定起始分支、数据和验收条件。使用同一模型配置和工具范围，记录能获得的用量指标及其计量来源。把缓存、网络波动和已有上下文作为影响因素记下来。一次快了几分钟只能说明这次演练的观察；多次小样仍需检查是否因题目熟悉而改变。不要把某个技能的安装量换算成团队收益，也不要将建议中的测试算成已执行。
深度配置：把稳定事实放在适当位置
先梳理项目结构和实际命令。哪段代码解析 CSV，哪段生成预览，测试怎样启动，哪些产物由构建生成，这些信息应能从当前文件验证。按 Claude Code 当前记忆文档选择项目说明的加载范围，在 CLAUDE.md 或相应项目规则中写入简洁、可执行的约定。每条命令先亲自复跑，标明依赖和成功信号。不要把一次故障的全部日志长期塞进每次会话都要加载的说明。
项目说明写清导入规则、测试夹具位置、允许修改的目录和验收方式。把长流程放到按需读取的文档或技能中，主说明给出入口。新会话先让助手说明会读取哪些规则、定位哪条导入路径，再核对当前源码。若它使用了旧启动命令，查清是说明未更新、加载位置不对还是另一个层级存在冲突。修改后用同一个最小任务复验，保留配置版本。
工具与扩展按本次用途启用。接口或服务确有必要时，先确认连接目标、访问范围、凭据提供方式和数据去向。先在隔离环境做只读小样，观察它实际返回的信息能否帮助定位。安装脚本可能改环境、拉取依赖或配置认证，使用前读清动作并保留恢复方式。配置指导文档本身不会自动证明本机配置成功，执行记录要与建议分开。
减少无效上下文：让每份材料回答一个问题
把故障输入整理成一张证据卡。写上预期三条、实际四条，附五行合成数据、导入入口和相关测试的位置。给助手明确问题：空白行在哪一步进入有效计数？先查解析、过滤和统计这条链，再根据观察决定是否读取其他代码。日志只截取同一请求的必要事件，附字段说明与请求编号。完整日志保存在本地可定位的位置，确有需要再读取指定片段。
长会话交接时，保存已确认的因果链、当前差异、执行过的命令、失败输出位置和未决问题。新会话先核对工作区和关键证据，再继续修改。摘要会丢失细节，重要断言要能回到夹具或源码。若上下文缩短后反复找错入口，就补充缺少的调用关系，而不是继续删必要事实。压缩的目标是少读无关信息，同时保留判断所需证据。
对很长的测试输出，用本地工具先提取失败测试名称、首个错误和日志路径，再把有意义的部分交给模型。保留原始输出，防止摘要漏掉上游错误。重复处理适合固定脚本时，脚本输出应有状态与可复查文件。独立调查可以有自己的上下文和有限产物，但额外调用、汇总与冲突处理也是成本。以端到端时间和正确结果判断是否值得拆分。
工程方法：从失败样本走到交付
先写一个能捕捉旧行为的检查，断言有效行数、跳过的空白行和缺编号错误。定位计数发生的位置，再修改负责过滤或统计的一处实现。检查不要仅断言导入请求成功。用旧实现和修复后实现跑相同夹具，保留失败与通过的对照，再补普通文件、仅空白行文件和包含多种换行的输入。保持错误行编号能让用户找到原记录，避免计数修复影响错误提示。
针对导入预览页面，可在修复后使用 Webapp Testing 做浏览器回归。该条目已核对，支持用 Python 和 Playwright 操作运行中的本地应用并保留脚本、截图和浏览器日志。提供演示站启动方式、合成文件和预期数量，检查上传后预览、错误提示与重试。解析器边界仍用项目测试覆盖；浏览器通过只代表所运行场景。提前准备浏览器依赖并核对脚本的读写与网络范围。
让审阅者从差异回答三个问题。修复是否对应已经证明的原因，夹具能否检测原故障，是否改变了本来应保留的行为。交付包保留任务规则、修复位置、检查结果、页面证据和未运行项。另一位维护者能按记录重跑后，再将稳定流程整理为可复用方法。更新项目说明时只加入长期有效的规则，临时诊断记录留在故障档案。
选文档型还是脚本型技能
需要理解配置选项和形成任务卡时，文档型能力可以帮助组织方案，输出应能对应官方文档与本项目事实。反复生成同类夹具或运行固定检查时，脚本型能力更容易形成一致产物，但必须核对依赖、输入格式和副作用。先用一份已标注的小样验证，记录固定来源版本。升级后重放同一小样，发现行为变化再判断是否迁移。标题相近的技能可能范围不同，不能只按名称替换。
常见问题
最值得先改哪一项？
先找基线中最常返工的环节。若每次都找不到入口，补项目说明与调用路径；若规则反复变化，先确认验收条件。瓶颈在测试启动时，优先修好环境。用观察决定次序。
用量减少是否说明效率提高？
还要看结果正确性、人工复核和遗漏。少读材料可能省了调用，却增加误修与补测。把同一输入、输出条件和总时间一起比较，保留指标来源和未测限制。
提示词与技能应该先做哪个？
单次任务先把目标、范围与验收表达清楚。重复流程稳定后再沉淀技能，降低重复解释。技能仍需要本次数据、版本与约束，不能代替任务定义。
多久能看到收益，下载量能作依据吗？
没有统一周期。先看连续几次同类任务的返工与完整交付时间。下载量只描述所注明平台和口径的活动，不能证明本项目适配，更不能替代小样验收。