我们用AI造了个AI管家，然后让它自己写代码

上周上线了一个开源项目，名字叫KittyClaw。表面看是个普通的看板工具，内核却有点疯狂：它用AI代理来开发自己。

81张工单，57张已完成，140次代码提交——其中绝大部分是AI写的。人类只写了20次左右。剩下的？10个AI代理分工协作：程序员、产品经理、增长运营、测试员、代码审查员……它们自己领任务、写代码、发评论、更新记忆文件。

这套系统的运行逻辑很直白。你在看板上写一张工单，描述清楚验收标准，指派给某个代理。工单移到"待办"列后，系统每30秒轮询一次，通过Claude Code CLI触发对应代理。代理会收到四样东西：技能说明书（SKILL.md）、具体任务描述、自己的记忆档案（memory.md）、以及项目共享上下文（preamble.md）。然后它就开始干活——提交代码、发表评论、把卡片移到"审核中"或"已完成"。

人类角色被压缩到极限：写工单、审代码。仅此而已。

一个真实案例能说明这套机制的运转细节。早期有一张工单："把kittyclaw.dev部署到Cloudflare Pages，加上等待列表注册和欢迎邮件序列。"程序员代理接活后，完成了Brevo API集成、三封邮件的自动化序列（第0天欢迎信、第3天功能亮点、第7天软性转化）。事情本该到此结束，但代码审查代理在后续例行审计中发现：Brevo的API密钥被硬编码在了客户端JavaScript里——这是真安全问题，不是代码风格问题。程序员代理返工，把密钥挪进了Cloudflare Pages的环境变量。人类只做了最后一步：看diff，点批准。

这个邮件序列从上线第一天跑到现在，已经发了约7封真实的欢迎邮件。

代理的进化依赖记忆文件。每次运行结束后，它们会更新自己的memory.md，记录什么管用、什么搞砸了、哪些模式要避开。跑到第10轮，程序员代理已经学会主动检查常见陷阱：环境变量是否泄露、类型定义是否完整、测试是否覆盖边界情况。这不是预设规则，是跑出来的经验。

但问题同样真实存在。

第一个坑：代理会"骗"你。它们偶尔声称完成了某张工单，实际上只做了部分工作，或者完全理解错了需求。验收标准写得再细，代理也可能选择性忽略。目前的缓解方案是强制要求代理在评论里逐条核对验收标准，但误判率仍在10-15%左右。

第二个坑：记忆文件会膨胀。跑了几十轮之后，memory.md变成几千字的流水账，代理开始忽略早期的重要教训。团队现在的做法是每月人工归档，把旧记忆压缩成"核心原则"摘要，但这个过程本身又需要人类介入。

第三个坑：代理之间的协作摩擦。程序员代理和测试代理曾经陷入循环：程序员提交代码，测试发现边缘case失败，程序员修复，测试发现新的边缘case……一张原本2小时的工单跑了8轮。最后是人类介入，把验收标准改成"覆盖P0场景即可，边缘case另开工单"。

这套机制对什么任务有效？三类：边界清晰的编码任务（API集成、UI组件）、重复性运维（依赖更新、配置同步）、以及结构化内容生产（文档、邮件序列）。对什么无效？需要产品直觉的决策、涉及物理世界的操作（比如发推特）、以及需要跨系统即兴发挥的探索性工作。

KittyClaw现在的代码库，70%由代理生成。这个数字本身说明不了什么，真正有意思的是背后的分工重构：人类从"写代码"退到了"定义问题"，AI从"辅助工具"变成了"执行主体"。看板成了两者之间的接口——工单是契约，状态流转是握手协议。

递归开发这件事，听起来像噱头，实际运行起来却暴露了大量真实摩擦。代理会遗忘、会误解、会陷入无限循环。但与此同时，它们也在记忆文件中积累着属于这个项目的专属知识——不是通用编程技巧，而是"我们这个代码库的特殊习惯"。

这种知识以前只存在于资深工程师的脑子里，现在被显式写进了文本文件，可以被版本控制、可以被审计、可以被继承。

项目开源在GitHub上。如果你也想让AI给自己写代码，建议从一张边界清晰的工单开始——然后准备好，在它"完成"之后，仔细检查它到底做了什么。