implement

实现

根据代码路径及其输出的消费位置，提供所请求行为的证据。为此次更改选择最小且有用的反馈循环；随着不确定性、集成程度或影响增大，增加验证力度。

用户的指示优先于此技能指南。沿用现有授权，并在范围内完成工作。必要时说明假设，以解决常规且可逆的选择。只有在缺少的信息会实质性改变结果，或适用边界要求时才提问；技能工作流本身不会构成新的审批门槛。

了解此次更改

编辑前检查仓库状态，并阅读涉及文件中已有的差异。将检出内容视为共享空间。保留非你创建的工作，并尊重已声明的所有权。

沿实际调用方和消费方追踪行为。找到最接近的相关模式、测试和实际门禁命令。问题涉及代码结构时，按语法搜索；查找名称和文本时，使用文本搜索。阅读足够的内容以理解更改，不要求读取最低数量的文件，也不必广泛倾倒上下文。

通过已配置的记忆工作流回顾不明显的既往决策。根据当前的一手证据或已安装版本，重新核实易变的 API、依赖项和部署相关说法。任务需要专门工具指导时再加载，不要猜测不熟悉的参数。

区分诊断与实现。“为什么会这样？”首先需要确认原因。获得修复授权后，定义一项能够区分故障行为与预期行为的检查。

选择可验证的工作切片

情况	下一步
明确、影响较小的编辑	进行编辑，并执行相关的结构或行为检查
存在可观察故障的 Bug	复现故障、隔离原因，然后验证修正结果
跨边界的新行为	实现一个带有测试的代表性端到端切片
共享接口或架构变更	更改契约前追踪消费者并检查兼容性
大型且不确定的更改	使用 plan 梳理依赖项和验收标准
可通过有效集成路径独立开展的工作	使用获准的委派方式并明确所有权

将实现与验证一并推进。若早期测试能够指导设计，不要把所有测试都拖到功能完成后再做。同样，也不要仅为走流程而给可逆的文本编辑创建测试。

按连贯的行为或契约边界拆分工作。文件数量和编辑次数都不是通用的节奏规则。在基于可能错误的前提继续构建之前，先运行能够暴露下一个潜在故障的最便宜检查。

让设计经得起审视

除非有具体问题足以证明偏离本地惯例是合理的，否则应遵循本地惯例。解释原因，而不是泛泛地偏好另一种风格。

压力	决策
出现新的模式或配置	将每一项与用户请求的行为或已证明的差异关联起来
同一决策在多个调用方中重复出现	为该决策指定一个合适的负责人
包装器只转发调用	移除前检查它是否承担了 API、策略或测试边界的约束
类型转换掩盖了不兼容的数据	在实际边界修正或验证契约
回退机制掩盖了错误	保留失败原因，并明确处理预期的恢复方式
兼容性代码不断增加	保留或删除之前，检查已发布版本的使用方和推出要求
复杂性持续增加	添加另一个特殊情况之前，重新检查所有权和数据流

即使只有一个调用方，只要抽象能强制执行真实的边界，它就可能有价值。如果更短的实现掩盖了错误行为或兼容性问题，那它反而可能更糟。应评估概念和契约，而不能只看代码行数。

将编辑限制在请求的范围内。移除因你自己的更改而产生的导入、过时标签和无效分支。如有要求，应通过项目的 sidequest 或问题处理流程转交无关发现；不要悄悄将其纳入实现。

出现规模问题时，应找出受到争用的资源。在问题根源处修复隔离、索引、批处理、所有权或容量。临时降低并发量或许有助于受控诊断或经授权的事故缓解，但不能悄然成为永久方案。

验证你打算做出的主张

根据实际仓库和受影响的行为选择检查：

检查	可以证明什么	常见局限
类型／静态分析	特定类型和结构属性	不会执行运行时行为
针对性行为测试	预期用例会经过变更路径	Mock 可能绕过集成
包或集成检查	受影响组件之间的契约成立	可能不涵盖打包或部署差异
构建／打包验证	可以生成制品	不能证明制品可以安装或使用
消费者检查	制品能为预期消费者提供服务	仅限于观察到的环境和用例

在快速迭代中使用范围明确的检查，并在相关提交或交付节点前运行仓库要求的门禁。若共享依赖、故障或剩余风险足以构成理由，再扩大测试范围。适当的检查通过后，就继续完成工作，不要反复运行无关的测试套件。

保留命令退出码和原始失败日志。通过管道传给 tail 可能会隐藏失败命令，除非妥善处理管道状态。捕获冗长日志后再进行总结。不要设置任意超时，也不要对其他 Agent 的工作运行自动修复。依赖筛选运行之前，先弄清实际测试框架的选择语义。

一份有用的验证记录应注明命令、修订版本或工作树状态、相关环境、退出状态，以及实际运行的内容。若筛选条件没有选中任何预期测试，就不能算验证了变更。只要输入一致，缓存结果也可以作为有效证据；应如实说明，而不要将其描述为刚刚执行的结果。仅凭墙上时钟时间，既不能证明做过工作，也不能证明门禁有缺陷。

检查使用边界

制品	有代表性的验证方法
生成的配置	检查组合后的输出是否满足促成该变更的不变量
软件包	安装并调用构建好的发行包，且不依赖未声明的同级依赖
UI	在真实界面中操作已变更的交互；若可用，使用 agent-browser
CLI	调用相关命令，包括受影响的错误／默认路径
数据库迁移	在有代表性的架构／数据上应用迁移，并检查兼容性或回滚要求
服务	确认正在运行的修订版本，并测试已变更的请求路径

检查不变量，而不只是确认“命令成功”。语法有效的选择器可能匹配不到任何内容。软件包可能成功构建，却漏掉导入器所需的文件。修复合并后，已部署的制品也可能仍未改变。

生产环境应用或其他会对外部产生实际影响的检查，仍须获得适用的授权。完成所有可用的本地验证，并说明剩余局限，不要暗示线上检查已经通过。

新检测器和防护措施需要正反两方面的证据：触发它们应当捕获的故障，并验证正常行为仍能通过。性能变更需要基线、有代表性的工作负载，以及相关资源测量结果。对于无法观察的界面，向人工检查者提供有区分度的操作流程和预期结果；不要编造截图或硬件测试结论。

通过更新假设恢复

再次编辑前，先对失败进行分类。环境故障、过时的产物、调用错误、共享输出竞争和运行时缺陷需要采用不同的应对方式。保留原始错误，并找出最先失败的依赖项，而不是修复所有下游症状。

修复无效时，说明结果证伪了什么，并选择一项能够区分剩余解释的检查。没有新证据却反复尝试不同变体，说明应当重新审视问题，无论尝试次数多少。不要用顺手重构来代替诊断。

在基线上出现的失败可以说明某个症状早于此次更改；追踪记录中没有出现更改过的文件名则不能。重跑成功并不能证明问题只是无害的偶发故障。在归因失败之前，请对比相同的命令、输入、修订版本和环境。详细的 CI 和事件处理流程见 references/recovery.md。

审查并提交完整工作

遵循项目的提交政策。项目要求原子提交时，应提交已验证的逻辑分块，而不是累积无关的工作。行为更改应与有助于理解该更改的测试放在一起。如果分开进行机械性移动能让审查更清晰，并保留有效的中间状态，就应将其分开。

暂存前，检查状态和差异。暂存明确归自己所有的路径或代码块，检查暂存补丁，并避免纳入他人的索引更改。遵循项目当前的消息格式和归属规则；共享索引处理、工作树、变基或冲突恢复请使用 git。推送、合并和发布权限由用户和项目约定决定，而非本技能。

在提交或集成检查点，将总差异与任务进行对比。测试全部通过也可能伴随着不必要的范围扩张。审查意见应有明确的作用机制和影响；应区分阻塞项与可选改进，而不是把每条建议都当作新要求。

在项目要求时，以及在确有必要应对重大风险时，应获取独立的对抗性验证。适用且可用时，使用 cross-model-review。不同模型可能揭示盲点，但无法消除相关错误。应根据证据核实核心发现，并使结论与所审查的状态相对应。审查未完成时，应如实报告。

保留状态并完成工作

在交接或压缩上下文时，保留原始结果、用户更正、变更路径、修订版本、已运行的检查、未解决的发现以及下一步。恢复工作时，先重新检查当前状态再继续；其他 Agent 可能已更改工作树。

如果将持久原因和修复记录在已配置的记忆中可以避免日后重新发现，就应记录下来。报告更改内容、原因、证明依据以及任何尚未验证的重要边界。继续完成已获授权的必要工作，直至相关结果得到处理。

证据与参考资料

审阅日期：2026-09-04。Astra 指南明确指出，小任务上的过度测试以及相互冲突的指令可能造成不必要的阻塞。此处按比例进行检查并以用户要求为先，旨在应对这些风险。

评估工作流效果或解读基准测试声明时，请阅读 references/benchmarks.md。进行 CI 问题分类、处理间歇性失败和恢复事件时，请阅读 references/recovery.md。这两份参考资料都不支持普遍适用的编辑比例，也不保证性能与模型无关。

反模式

反模式	更好的做法
随意编辑若干次后再验证	在依赖新的不确定契约之前先验证
小改动也运行所有测试套件	运行必需且相关的检查；基于证据说明理由后再扩大范围
不检查覆盖范围就接受绿色徽章	检查实际运行了哪些内容，以及它支持了哪些断言
仅凭空搜索结果就称问题早已存在	比较受控执行并追溯因果关系
因兼容性代码看起来过时就将其删除	检查消费者和发布义务
每个常规选择都请求许可	在执行过程中沿用现有授权
把审核者批准视为消费者验证	在使用其输出的地方测试变更后的行为

此技能不是什么

• 固定的步骤顺序、编辑次数上限、强制研究阶段或 Agent 配额。
• 更改相邻代码、绕过审批或声称运行了实际未运行的检查的许可。
• 取代理解实际实现及其消费者的做法。