基于大模型和 Coding Agent 能力的突飞猛进，最近几个月，我的「古法编程」率成功的由 10% 变成了 0% —— 基本没有一行代码是我手写的。然而生产力的提升却暴露出了现有大模型在长程代码开发上的很多短板：在 Opus 和 Sol 代替我通宵达旦的写下一行又一行代码的同时，它们也为我写出了一个又一个的逻辑陷阱和 BUG。在与 AI 不断的斗智斗勇和不断的翻车中，我沉淀出了几个可面向所有代码项目开发 skill，它们都诞生于一个共同的短板：一套在大模型看来「看起来成功」的代码，其实满是漏洞和缺陷。
<code>false-green</code> —— 当 Agent 自认为自己的测试代码有用
一键安装：<code>npx skills add shaokeyibb/hikarilan-skills --skill false-green</code>
在日常开发中，为了确保代码的质量，开发者一般都会为项目建立丰富且复杂的单元测试 —— 大模型也会。然而很遗憾的是即使是目前的主流 SOTA 大模型仍然未能学会写出「高质量且真正有用」的单测代码，它们经常写出一些「为了覆盖率而覆盖」的单测，实际上这些单测没有拦住任何问题。而如果这些单测代码只是单纯占用 CPU 资源做无意义的事情也就罢了，更可怕的是，这些无意义的单测代码会影响大模型对代码质量的判断，就像你看到一套单测设计完美的开源项目的时候会先入为主的认为这个开源项目没有任何质量问题一样。
因此，<code>false-green</code> 就是在假设这样一种情况：虚假的单测通过远比失败的单测更加糟糕。举个例子，一段测试代码看似有非常完善的逻辑分支，以尽量覆盖所有可能的测试用例，但是最后一行 <code>return true</code> 却静默跳过所有前序检查，直接返回虚假的成功 —— 大模型很难一眼看出来这种问题，就像人类很难一眼看出来一样。
为此，<code>false-green</code> 对于可能会出现上述问题的单测，要求大模型首先考虑「测试是否真正覆盖了其所生成的逻辑」，并要求大模型在编写完任意一条单测的时候对该单测进行“变异”，即通过 monkeypatch 或其他方式模拟一个故障的场景，来检查该单测是否真正会如预期失败，真正避免出现上述「假绿」的情况。
<code>delegating-to-agents</code> —— 决定何时委派子代理，并进行对抗审查
一键安装：<code>npx skills add shaokeyibb/hikarilan-skills --skill delegating-to-agents</code>
第一次看到子代理模式是从 Superpowers 的 subagent-driven-development，其提供了一套「主代理负责决策和协调，子代理负责实现」的模式，当时看到就觉得眼前一亮，因为其很好的解决了大模型上下文窗口不足导致实现细节丢失的问题（那会儿主流大模型上下文窗口还是 256K，现在 SOTA 模型基本都是 1M 起步了），但实践过程中仍注意到很多问题，其中一个点就是很难控制子代理代码的质量，子代理的实现对于主代理来说是个黑箱，而主代理往往又不会主动核查子代理的实现质量，即便核查，也很难确保全面。
<code>delegating-to-agents</code> 同样实现了子代理模式，但除此之外，它重点提及了两点：
- 移交已建立的状态信息。 说明哪些检查已通过（绿色），哪些失败（红色）是已知的，以及失败的原因。如果没有这种机制，Agent 的大部分运行时间都会耗费在应对环境噪声上，而不是执行实际任务 —— 而且对于未亲历现场的人来说，这些噪声看起来就像是真实的发现。
- 在将主张视为确凿证据之前，务必先进行核实。代理程序或人员提交的报告仅代表一种“主张”。在亲自核实之前，应当认为主张都未经证实。
通过这两点，主 Agent 得以更好的把握子 Agent 的代码实现质量，并得到更全面的审查报告，以进行更高质量的修复。
<code>concurrent-worktrees</code> —— 多 Git Worktree 并发开发方法论
一键安装：<code>npx skills add shaokeyibb/hikarilan-skills --skill concurrent-worktrees</code>
当项目时间周期很紧张的时候，经常会派多 Agent 面向多个独立需求进行并行开发，如果是互不相关的小需求，在同一个代码仓库开发尚且可以，但一旦是相互耦合的大型需求，这种模式就完全不可用，会导致 Agent 之间相互打架，甚至发生一个 Agent 把另一个 Agent 的工作全部 <code>reset</code> 掉的情况。
事实上，Git 支持这种在同一代码仓库进行并发开发的需求，并提供了 <code>Worktree</code> 这样的机制，允许你在不同的位置建立不同的分支，并行开发，并允许你将代码合并回主线。然而大模型日常对于 Git Worktree 的使用显然还并不熟练，经常会出现很多坑，因此，<code>concurrent-worktrees</code> 面向一些常见的最佳实践，提供了一套方法论，以尽量避免大模型在使用 Git Worktree 进行并发开发的过程中出现严重的代码丢失问题。
<code>batch-closeout</code> —— 从多个角度进行批次收尾和验收
一键安装：<code>npx skills add shaokeyibb/hikarilan-skills --skill batch-closeout</code>
<code>batch-closeout</code> 允许 Agent 在进行多个批量工作的时候，延后相同类型需求的验收以避免浪费时间，而是在这些需求（「批次」）完成后，从多个角度一起进行批量收尾和验收，以在提升代码开发效率的同时避免代码质量降低。
如何使用
这几个 Skill 已经被我开源到了 GitHub 上，你可以访问 hikarilan-skills4 来获取它们（如果觉得不错别忘了给我点个 Star），除了适用于 Claude Code 以外，这些 Skill 还支持任何符合 Agen Skills 规范的 Agent，无论是 Codex、Codebuddy 还是 Hermes Agent。
最后，基于我个人的最佳实践，我也建议你将这些 skill 和 Matt Pocock Skills3 一起使用，以达到最佳效果。
Enjoy!
