先写任务边界和可观察结果

先用一段话说明要改变的行为、触发条件和预期结果，再列出本次允许修改的目录。把现有分支、工作区改动和并行任务的文件范围记录下来，让助手知道哪些内容必须保留。对于跨服务任务，标注请求从入口到数据层的最短路径，不需要默认上传整个仓库。

加入适用的仓库说明与运行约束，例如依赖管理方式、数据写入授权和对外错误脱敏。把不能确定的事实标为待确认，不要用过时的架构描述填空。任何凭证、生产配置和真实用户数据都不属于上下文包。

按依赖挑选材料并保持来源

从入口文件开始，提供它直接调用的接口、类型与相关测试，再补充必要的配置模板。文件路径和版本比粘贴一段没有来源的代码更有用。长文件可以截取与任务有关的函数，但要保留签名、输入输出和错误处理的上下文，避免片段误导实现。

加入一个可以稳定复现问题的无敏感样本和明确的验收命令。将安装、构建和测试要求分开，说明哪些操作会连接外部服务或产生费用。对缺失依赖和无法运行的环境如实记录，不能把“未执行”改写成“通过”。

随着证据扩展，而不是一次塞满

让助手先说明还缺什么材料，按具体依赖补充。新增上下文时保留任务边界，防止从局部修改扩展为无关重构。若发现实际问题跨越更多目录，先把新范围及原因记录清楚，再决定如何分阶段实现。

完成后按原始验收条件审阅 diff，确认上下文中的假设是否得到验证。保存有用的说明到仓库适当位置，清理确认无用的临时副本。上下文包的价值是帮助定位和复现，不是越长越好；实际输入用量与当前模型支持范围仍要单独核对。

参考资料

由 NexoToken 维护的自营资料站。平台介绍包含运营方利益关系，不构成独立第三方认证。