incremental-implementation

incremental-implementation 技能概览

incremental-implementation 技能帮助你把代码分成小而可运行的片段逐步交付，而不是试图一次性完成一个大改动。对于 Code Editing 工作流中的 incremental-implementation 来说，它尤其适合跨多个文件、需要测试，或者风险足够高、一次大改很难排查问题的任务。

当你希望在不中断功能推进的前提下，稳妥地保持正确性时，这个技能就很实用。它要解决的核心问题很直接：把工作拆成一连串“实现—测试—验证”的步骤，让每个切片都保持可审查、可测试，并且在出错时更容易恢复。

最适合的场景，以及为什么重要

这个技能特别适合特性开发、重构，以及那些第一版很容易超出你当前可一次性验证范围的改动。对于很小的单文件修改，它的价值就没那么高，因为切片带来的流程开销可能会大于收益。

它和其他方法有什么不同

它不像那种泛泛的“迭代式工作”提示词，incremental-implementation 提供的是一套具体的执行模式：先做最小的完整改动，验证它，再继续下一步。这种纪律性可以减少隐藏耦合，把回归影响控制在局部，也能帮助 agent 在反馈到来前避免过早过度设计。

用户最关心什么

读者通常最在意三件事：这个技能是否真的能降低风险、需要多少前期规划、会不会拖慢速度。这里的答案是：它应该通过减少返工来加快复杂任务的推进，但前提是你愿意先定义好切片边界，并对每一步做验证。

如何使用 incremental-implementation 技能

安装技能并找到源文件

使用下面的命令安装 incremental-implementation install 包：

npx skills add addyosmani/agent-skills --skill incremental-implementation

然后先读 SKILL.md。在这个 repo 里，它就是唯一的权威来源；没有额外的 rules/、references/ 或辅助脚本需要你去追。若你想尽快上手，就先看“什么时候使用它”和“增量循环”相关的部分。

把模糊任务拆成切片

最好的 incremental-implementation usage，从一项已经被拆成结果的任务开始，而不是一个笼统的大需求。好的输入长这样：

• “把用户资料编辑拆成三步：表单渲染、保存 API、校验/错误状态。”
• “增量式重构解析器：保持现有行为，先补测试，再移动逻辑。”
• “实现仪表盘筛选器：先做可用的 UI，再做持久化，最后处理边界情况。”

较弱的输入像这样：“让应用支持资料。” 这会迫使技能自己猜切片边界，而这正是实现质量容易下降的地方。

跟着循环走，不要盯着整个功能

一套强的 incremental-implementation guide 应该是：实现最小的完整切片，运行相关测试或构建，验证行为，然后再进入下一切片。如果某个切片没法测试，就把它切得更小；如果没法验证，那它大概率还是太宽了。

面向 Code Editing 的实用工作流

对于 incremental-implementation for Code Editing，你可以要求 agent 在每一步后保留可工作的状态，避免大范围重写式修改。一个好用的提示词结构是：

使用 incremental-implementation。把这个任务拆成 3-5 个切片。每个切片只改必要的文件，说明对应的测试或验证步骤，并且如果这个切片会让应用处于破坏状态就停下来。

这个提示词之所以有效，是因为它限制了范围，强制设置检查点，并且让 agent 在改太多代码之前先把取舍说清楚。

incremental-implementation 技能 FAQ

incremental-implementation 只适合大功能吗？

不是。只要一次性改完会增加风险，它就适用。尤其是在需要测试、存在跨文件依赖，或者第一轮就可能暴露未知问题时，incremental-implementation skill 会特别有帮助。

我需要把整个工作流都改掉吗？

不需要。你完全可以保留原有技术栈，只改变执行顺序：先切片，再验证，然后继续。这个技能讲的是实现纪律，不是新的框架或工具链。

什么时候不该用它？

如果是单个函数或单个文件的修复，而且已经很清楚，就可以跳过它。任务很小、理解很明确时，增量规划反而可能带来不必要的流程感。

对新手友好吗？

可以，只要你能用基础层级描述一个功能，并接受分步推进。对有经验的开发者也同样有用，因为它能防止“差不多完成了”的代码在没有验证的情况下越积越多。

如何改进 incremental-implementation 技能

给出更清晰的切片边界

最大的质量提升，来自你明确告诉 agent 每个切片该在哪里结束。可以加入这样的约束： “每一步之后都要保持应用可构建”、“在 UI 跑通之前不要改 schema”、“先加测试，再碰 API 层”。这些边界会让 incremental-implementation usage 可靠得多。

一开始就提供正确上下文

提前分享入口点、当前文件和任何硬限制：框架版本、测试命令、迁移约束，或者绝对不能改动的文件。如果 agent 需要在执行中途自己发现这些限制，它可能会选出技术上确实是增量、但合并起来却很别扭的切片。

注意最常见的失败模式

最常见的失败模式，是切片太大，没法干净地验证。如果第一次输出看起来还是太宽泛，就要求它给出更小的下一步、更紧的测试计划，或者更窄的文件范围。更好的结果通常来自在改代码之前先缩小范围，而不是改完之后再补救。

每个切片后都继续迭代

把第一轮当作计划，而不是最终答案。每完成一个切片，就告诉 agent 哪些通过了、哪里坏了、还有哪些地方仍然让你觉得有风险。正是在这个反馈回路里，incremental-implementation 技能才最有价值：它把一次性的请求，变成一串受控的代码修改。