Claude Code玩7万行代码项目：1人干4人活

7万行代码，2400+测试用例，4个代码仓库，1个开发者。Manasight作者用Claude Code写代码不稀奇，稀奇的是他把测试环节也丢给了AI——自己在玩《万智牌》的时候，后台Agent正在自动提交Bug报告。

这听起来像科幻场景，但数据很实在：传统单人开发要么跳过QA，要么停止迭代。他找到了第三条路。

从"写代码更快"到"测试方式质变"

作者最初期待AI辅助开发能提升编码速度，确实做到了。但真正的意外收获是测试和调试环节的结构性改变。

Manasight是一款《万智牌：竞技场》的桌面覆盖层工具，技术栈是Tauri应用（Rust后端+TypeScript前端），搭配Astro官网。这类游戏辅助工具有个致命痛点：开发者无法同时扮演玩家和测试员——你不能一边打自己的牌，一边调试覆盖层在牌局中的实时表现。

更麻烦的是跨平台验证。41个测试用例的平台验证协议，要跑遍4种操作系统。传统模式下，这是4个全职QA工程师的工作量。

作者的选择是重构测试流程本身，而非压缩测试范围。

Claude Code的两张底牌：Slash命令与Agent

Claude Code是Anthropic推出的终端AI编程助手，核心能力是访问代码库、读写文件、执行Shell命令、调用工具——全部在对话流中完成。

对测试场景真正有用的，是两个特定功能。

Slash命令是可复用的提示脚本。用户用Markdown定义工作流：读取哪些文件、调用什么工具、遵循什么规则、输出什么格式。运行时输入/command-name即可触发。作者把它理解为"可执行的运维手册"，目前已配置调试、反馈分类、代码审查、GitHub Issue转PR等场景。

Agent是后台运行的Claude实例。父对话派生它们执行特定任务（如"追踪这段代码路径并汇报发现"），完成后返回结果。关键特性：不阻塞主线程，用户继续工作。

这两个功能的组合，让"异步QA"成为可能。

/debug-game：把游戏时间变成测试时间

作者写了一个叫/debug-game的Slash命令，专门用于实时QA会话。

流程是这样的：启动《万智牌：竞技场》，运行Manasight，开始一局对战。当覆盖层出现异常——卡牌追踪缺失、延迟 spike、面板位置偏移——直接在Claude Code对话中描述问题，或者说"查看最新截图"。Claude已配置截图文件夹路径，无需手动传文件。

QA会话期间不修改代码。Claude启动多个后台Agent并行调查：一个追踪从游戏事件到解析器再到覆盖层的完整代码路径，一个检查Manasight应用日志的错误，一个读取Arena的Player.log确认游戏客户端实际上报了什么数据。

每个Agent独立工作，父对话保持响应。作者继续打牌，继续发现问题，继续口头或文字报告。

会话结束时，输出是一份结构化追踪表。每条发现标注类型（Bug、性能问题、UI问题）、严重程度、初步根因、建议修复方案。

传统测试的上下文切换成本被抹掉了。不需要从"玩家模式"切到"调试模式"再切回来，不需要手动翻日志、比对时间戳、复现步骤。描述问题的同时，调查已经在后台进行。

从"我测"到"它测"：测试权的转移

这个模式的核心变化，不是"用AI帮忙测试"，而是"把测试执行权部分让渡给AI"。

作者保留了两个关键决策点：发现问题的时机（仍然需要人类玩家感知异常），以及修复方案的终审（仍然需要人类开发者判断）。但中间的信息收集、日志关联、根因定位，被批量自动化了。

这带来一个反直觉的结果：测试覆盖率反而可能提升。因为执行成本趋近于零，作者愿意在更多场景触发/debug-game——休闲对局、排位赛、特殊赛制，都成为测试机会。传统QA需要专门排期的"测试窗口"，现在嵌入日常游戏行为。

另一个隐性收益是知识沉淀。每个Slash命令都是可版本控制的工作流定义，Agent的调查路径被结构化记录。新人（或未来的自己）可以复现相同的诊断逻辑，而不依赖个人经验。

边界与代价：什么没变

作者没有回避限制。

Agent的调查深度受限于提示工程的质量。如果Slash命令对某类错误模式的描述不够精确，Agent可能漏掉关键线索，或者给出误导性的根因假设。这要求开发者持续迭代命令模板，本质是把个人调试经验编码为可执行文档。

实时QA仍然需要人类在场。AI可以并行分析，但无法替代玩家感知"这里有点不对"的直觉。游戏覆盖层的用户体验问题，往往始于细微的延迟感或视觉错位，这些信号很难用断言捕获。

跨平台验证的物理约束也在。Agent可以分析代码逻辑，但无法替代在真实Windows/macOS/Linux设备上的渲染测试。41个测试用例的平台协议，AI辅助的是执行和分析，不是硬件环境的魔法变出。

单人开发的产能天花板，被重新计算了吗

Manasight的案例提供了一个具体参照：7万行代码规模、4仓库架构、多平台交付，传统团队配置可能是1主程+1前端+2QA。作者用AI工具链把人头压到1个，且未牺牲测试深度。

这引出一个开放问题：当AI能承担测试执行、日志分析、初步诊断这些"高耗时、低创造性"环节，单人开发者的产能上限由什么决定？

是架构设计能力——因为代码复杂度仍在膨胀，需要人类把控模块边界。是问题定义能力——因为AI擅长"解决"，但"发现值得解决的问题"仍然依赖人类判断。还是提示工程能力——因为工具链的效率，最终取决于开发者能把多少隐性经验转化为可复用的命令模板？

作者在文末留下了一个细节：他的下一个Slash命令计划，是让Agent在发布前自动跑一遍"用户最可能吐槽的10个场景"。这些场景来自GitHub Issue的历史聚类，但优先级排序仍然是他手动调整的。

AI测了代码，但"什么值得测"的决策权，还在人手里。这个分工边界，会是暂时的，还是结构性的？