代码工厂夜未眠：我让AI（Droid Mission）造了30小时轮子，发现了软件开发的天花板不在代码里

素材来源Droid Mission 模式完整产物208个文件 5个内置技能提示词的完整解构开端那个让我睡了个安稳觉的夜晚周四晚上十一点我给电脑接了电源对AI说了一句开始吧。然后我关掉屏幕上床睡觉。周五早上八点我打开电脑发现它还在跑。终端里的日志像瀑布一样滚动文件数从昨晚的几十个变成了上百个。周六中午它停了。208个文件7个里程碑全部绿灯319个断言一次性通过。我全程没碰键盘。这不是科幻小说这是上周末真实发生在我电脑里的事。一个我连Hello World都写得磕磕绊绊的人让一个AI agent从零开始连续跑了30多个小时交付了一套功能完整的物业管理系统。你可能会说又是AI写代码的老生常谈这种demo我看多了。但这次真的不一样。它不是那种给我写个登录页面然后AI吐出一堆代码的玩具。它是一条完整的、自运行的、有纪律的软件生产线。从写第一行代码开始到最后一个测试用例通过为止中间的测试、审查、发现bug、修复、回归测试、知识沉淀——全自动零干预。我睡觉的时候它在写代码我吃饭的时候它在修bug我看剧的时候它在跑测试。它比任何人类程序员都更有耐心更守纪律更不偷懒。本文不是一篇AI真厉害的赞美诗而是一次彻底的、诚实的解剖实验。我会把它30个小时里做的每一个动作、遵循的每一条规则、踩过的每一个坑连同它内部那5个像操作系统内核一样的提示词一并拆开给你看。因为它的真正价值不在于AI能写代码——这是2023年的新闻了。它的价值在于它定义了一种全新的、有纪律的、可重复的、自带质量保证的软件开发范式。第一章我们现在的开发流程问题出在哪让我们先退一步看看我们现在是怎么造软件的。一个典型的软件开发周期是这样的产品经理写一份长达几十页的需求文档PRD然后扔给开发团队。开发Leader把文档拆成任务分给组员。大家开始写代码写完在本地跑一下感觉没问题了就提交。测试团队介入开始测发现一堆bug打回。开发修bug再提交。再测可能发现新bug——有时候修一个bug能引出三个新bug。反复几轮直到所有人都精疲力竭说差不多了上线吧。然后用户开始用发现问题更多。这个流程的致命缺陷是什么它的质量保证体系是建立在人的意愿和注意力之上的。需求文档写得清不清楚靠产品经理的意愿。开发理解得正不正确靠程序员的注意力。测试覆盖得全不全面靠测试工程师的耐心。代码审查严不严格靠团队Leader的精力。人是最不靠谱的。人会累会烦会走神会有情绪。你让一个人连续工作30个小时不犯一个低级错误这是不可能的。你让一个人对每一个API端点都写测试、对每一个边界条件都验证、对每一行代码都审查——他做不到也没那个心气。结果就是大部分项目的质量是一个概率问题碰到靠谱的人项目就稳碰到不靠谱的项目就是一座屎山。而且即使是最靠谱的团队也会在赶工期的时候走捷径。“这个测试先跳过吧后面再补”——然后永远没补。“这个bug不重要先记着”——然后永远没修。人和纪律的矛盾是传统软件开发的天花板。但是如果我告诉你有一个系统能做到下面这些事呢连续工作30小时注意力从不涣散对每一个功能点不是大概测一下而是生成精确的、可追踪的319个断言有一个独立的、永不疲倦的代码审查员逐行审阅代码发现问题后给出文件名、行号和具体的修复建议修复完代码后不是只测修过的地方而是把整个系统的测试全部重跑一遍全量回归确保没把别的地方搞崩每一个阶段踩过的坑、学到的经验都自动记录下来变成下一个阶段工人的操作手册这个系统就是Droid Mission 模式。第二章把软件工厂搬进电脑里Droid Mission 这个名字听起来挺唬人但它的核心思想其实很朴素把软件开发当成造汽车把AI当成工厂里的工人。你想想丰田的工厂是怎么造车的建厂房水、电、气、传送带全部就位。写手册每个工位的标准作业程序SOP写得清清楚楚。培训工人每个工人只负责一个环节但要做到极致。流水线作业一辆车从底盘到总装经过几十个工序每个工序都有严格的质量检查。质检与返工不合格立刻下线返修修完再从这个工位开始走。总装验收所有零件组装完还要最后跑一圈测试场。Droid Mission 就是把这套工厂逻辑用代码和提示词实现了。AI agent 在其中扮演了所有的蓝领和白领角色拧螺丝的工人、盯工序的质检员、写工艺手册的工程师、甚至管整条产线的车间主任。最关键的设计是它不是一个超级AI一口吃成胖子而是把一个大项目强制拆成了7个独立的、有先后顺序的里程碑。上一个里程碑的验收章没盖下一个里程碑的工人绝不开工。这就好比盖楼。地基不打完、不验收谁也不许往上盖第一层。一楼不封顶、不验收谁也别想盖二楼。每一层都有独立的验收签字。区别在于在这里签字的人是另一个AI。下面我们就走进这座工厂看看它的每一道工序是如何运转的。第三章先把厂房的水电煤接通在任何代码被写出来之前Droid 做的第一件事是环境初始化。它生成一个services.yaml文件相当于工厂的基建图纸services:mysql:start:docker compose up-d mysqlhealthcheck:docker compose exec mysql mysqladmin ping-h localhostport:3306backend:start:docker compose up-d backendhealthcheck:curl-sf http://localhost:3100/api/healthport:3100depends_on:[mysql]frontend:start:docker compose up-d frontendhealthcheck:curl-sf http://localhost:3101port:3101depends_on:[backend]这个文件定义了三个核心服务数据库、后端、前端、它们的启动命令、健康检查方式、以及依赖关系。Docker 容器技术保证了环境的一致性彻底解决了在我电脑上能跑啊这个千古难题。接着它会生成一个init.sh脚本。这个脚本是幂等的——你跑一次和跑十次结果完全一样。它会智能地等待MySQL和后端服务真正就绪最多等60秒不是傻等也不是不等确保后续的工人进来时灯是亮的水是通的机器是转的。这就是工厂的水电煤。基础设施不稳后面一切免谈。第四章Mission的操作系统——5个控制一切的技能文件上面这些是你能看到的产物。但这次我还挖到了更底层的东西Droid Mission 的5个内置技能提示词文件。它们是这座工厂真正的操作系统源码。┌─────────────────────────────────────────────────┐ │ mission-planning.md │ │ 规划层唯一能和人类说话的模块 │ │ 7个Phase3个强制人类确认的检查点 │ ├─────────────────────────────────────────────────┤ │ define-mission-skills.md │ │ 设计层定义Worker技能并声明系统会注入验证器 │ ├─────────────────────────────────────────────────┤ │ mission-worker-base.md │ │ 执行层所有工人上岗前必读的员工手册 │ ├────────────────┬────────────────────────────────┤ │ scrutiny- │ user-testing- │ │ validator.md │ validator.md │ │ 代码审查员 │ 用户测试员 │ └────────────────┴────────────────────────────────┘这五个文件的分工异常清晰mission-planning唯一的人类接口。它负责和你沟通拆解任务。在7个规划阶段中有3个是INTERACTIVE的必须你点头才能往下走。define-mission-skills它是教练的教练。它不干活它负责定义每个工人应该怎么干活。并且它明确声明系统会自动注入两个验证器。mission-worker-base所有工人的通用BIOS。任何一个工人不管你是做后端的还是写前端的上岗前必须先跑一遍这里的启动自检流程。scrutiny-validator和user-testing-validator这是两个守护进程。它们不由任何人调度当某个里程碑的所有代码任务完成时它们自动触发。最后一点是精髓。define-mission-skills里是这么写的“The system automatically injects two validation features when a milestone completes… You do NOT create these yourself — they are auto-injected by the system.”翻译过来就是验证不是工人自觉做的事是系统强制做的事。工人想偷懒跳过测试没门。工人想绕过代码审查做不到。验证工序是刻在流水线上的你不走这道工序产品就下不了线。这就像工厂里的自动质检机——不是你走到半路想起要检查而是流水线走到那个位置机械臂自动把你做的零件抓过去扫描不合格就直接踢出传送带。第五章人与AI的楚河汉界——Planning阶段的精妙设计mission-planning.md展示了一个极其成熟的设计它把人与AI的权责边界画得非常清楚。Phase做什么主导者需要人类批准吗1. 需求理解主动问你问题澄清模糊地带AI提问是关键节点2. 识别里程碑AI自己分析把大需求拆成小目标AI自主否3. 确认里程碑把拆好的里程碑展示给你看等你确认人类是关键节点4. 基础设施规划检查你的电脑环境规划服务配置AI检查建议是关键节点5. 凭证设置如果需要第三方API引导你配置好AI引导是6. 测试策略设计测试方案AI设计你确认策略7. 创建提案生成最终的《施工方案》文档AI自动系统接收人类只在三个地方被要求介入确认做什么里程碑、确认在哪做基础设施、确认怎么做凭证。这三件事一旦敲定后续30多个小时的编码、测试、审查、修复——再不需要你操一秒钟的心。这个设计的核心哲学是人类负责做决策AI负责做执行。边界清晰责任明确。这个阶段还有几个细节让我拍案叫绝1. 不假设原则“Ask clarifying questions. Don’t assume.”我们见过的绝大多数AI你给它一个模糊的需求它二话不说就开始生成然后给你一堆你根本不想要的垃圾。而这个系统它会主动追问你直到它真正理解你要什么。2. 先检查再规划原则在规划基础设施时它不会武断地说我要用3306端口而是会先运行命令检查你的电脑lsof-i-P-n|grepLISTEN# 看哪些端口被占了dockerps# 看哪些容器在跑了psaux|grepnode# 看哪些Node进程活着然后它会根据检查结果避开你已有的服务选择一个空闲的端口。这是智能更是教养。3. 强制性的Dry Run预演在写任何一行代码前系统会强制要求进行一次测试预演。原文用了大写的REQUIRED。“You must run a validation readiness dry run… Do NOT proceed until the dry run is complete…”它的逻辑很简单连测试环境都跑不通你写出来的代码怎么验证这不是浪费时间这是从源头杜绝返工。更绝的是这个Dry Run会测量你的电脑资源消耗然后计算出我最多能同时跑几个测试验证器而不把你的电脑卡死。它用了一个70%资源余量的安全规则。举个例子你的应用一个实例吃2G内存一个浏览器测试会话吃300M。你的电脑总内存18G可用余量12G。按70%算可用8.4G。那么同时跑3个验证器6.9G没问题跑4个9.2G就超预算了。所以最大并发数就是3。这不是拍脑袋这是精算。它在为你考虑它怕把你的电脑搞崩。第六章知识库——不只是文档是活的工艺手册工厂和流水线都好了工人上岗前需要培训。知识库就是培训手册。1. 架构宪法 (architecture.md)这个文件定义了系统的7个业务模块限界上下文。但它做得更聪明的是它把复杂的业务抽象成了3种核心模式其中最典型的是Plan-Task-Record计划-任务-记录保洁任务用这个模式定计划-生成任务-执行记录巡检任务用这个模式绿化养护也用这个模式。当你把一个系统的复杂度收敛到几种模式后代码的复用性会指数级上升。这就是为什么后面的m4-cleaning保洁模块能一轮过因为这个模式在前面的里程碑里已经被反复打磨成熟了。2. 测试百科全书 (user-testing.md)这里面最有价值的部分叫“Discovered API Quirks”已发现的API坑比如维修工单的启动接口是POST /api/maintenance-orders/:id/start而不是你以为的通用PATCH。紧急事件上报接口是POST /api/security/emergencies不是/api/emergency-incidents。创建服务请求时不能传priority字段否则会报错。这些坑不是一开始就写在文档里的它们是AI在前面模块的开发测试中一个个踩出来、并记录下来的。这就像一个老师傅带徒弟一边干一边说“记住喽这个螺丝要反着拧。”3. 知识库的自动更新机制user-testing-validator.md中有一条铁律“Collect frictions, blockers… For each… if it reveals something factual and useful… update .factory/library/user-testing.md”原来知识的沉淀不是靠某个工人的自觉而是验证器层面的强制流程。每次测试跑完验证器会自动扫描所有报告把其中有价值的摩擦和经验提取出来写回知识库。知识不是靠自觉积累的是靠系统自动提取的。这套机制比任何公司花几十万买的知识管理系统都有效。第七章一个AI工人的上岗SOP标准作业程序每个Worker无论是写后端的还是做前端的启动时都必须严格执行mission-worker-base.md定义的7步上岗流程一步都不能跳读取上下文并行读取任务书、架构图、服务配置等。初始化环境运行init.sh反正它是幂等的跑不坏。基线验证跑一遍全量测试确认当前的环境是健康的。理解上下文看看同里程碑下其他功能是怎么做的。查阅知识库看看前人留下了什么坑。在线调研遇到没见过的技术先上网查别瞎写。启动服务按依赖顺序把数据库、后端、前端都拉起来。第3步基线验证是灵魂。规则说“If baseline fails: Call EndFeatureRun… and explain the broken baseline”翻译如果基线测试跑不通工人严禁尝试自己去修必须立刻停工上报问题等待处理。为什么因为你不知道是环境坏了还是上一个人留下的代码是烂摊子。在一个不健康的环境上继续码代码等于在流沙上盖楼盖得越快死得越惨。第一时间上报而不是自作聪明地修一修这是工业级的纪律。从这份员工手册里我还挖出了几条看似离谱实则充满智慧的安全规则.factory/目录是禁地任何工人严禁重命名、删除或修改该目录下的任何文件。这是工厂的系统文件碰了系统会崩。严禁killall用户进程你不能因为自己要3000端口就把我正跑着的其他项目给杀了。你只能杀你自己启动的进程。严禁在测试命令后使用管道| tail或| head这条太经典了。在Linux里npm test | tail -10如果测试失败了但因为用了管道系统会返回最后一个命令tail的退出码通常是0代表成功。结果就是测试明明红了一大片但系统报告的是全部通过Droid的规则是宁可输出再长再烦也不允许掩盖真实的失败信息。交接后立刻下岗干完你的活儿调用EndFeatureRun之后必须立刻结束你的回合。别多管闲事别碰别人的活儿。边界清晰才不会乱。第八章Handoff设计的黑暗森林法则——假设所有工人都会偷懒这是整个Mission设计里我认为哲学意味最浓的一章。define-mission-skills.md里有一段话堪称AI Agent设计领域的黑暗森林法则对抗性思考For each worker type, ask:‘What steps might a worker skip when rushed?’‘What would the handoff look like if they skipped it?’… Then design handoff requirements that demand those details.设计流程时不要假设执行者会完美执行而要假设他们一有机会就会偷工减料。然后设计一个让偷懒行为无法遁形的交接机制。这和安全领域的威胁建模异曲同工——别假设用户是好人假设他们都是潜在的攻击者。如何让模糊回答变得不可能“Structure handoff fields so that vague answers are obviously incomplete. If a worker can write ‘tested it, works’ and satisfy the requirements, the handoff is poorly designed.”如果交接单允许你写已测试没问题就算过关那工人就一定会这么写。不是因为他们坏而是因为LLM的天性就是倾向于生成看起来合理但经不起推敲的文本。那怎么办系统定义了一套强过程。弱过程给偷懒留足了空间Build the UITest it worksRun validators强过程让偷懒无处遁形Write tests first (red), then implement to make them pass (green). Cover rendering, validation, submit behavior, error display.Verify every user flow withagent-browser.Each flow tested oneinteractiveChecksentry with the full sequence and end-to-end outcome.Runnpm run typecheckandnpm run lint.区别在哪弱过程把什么叫做好了的定义权交给了执行者强过程把定义权牢牢握在设计者手里。开发一个用户管理页面是弱过程是愿景。先写测试覆盖渲染、校验、提交、错误处理四种场景再用agent-browser把每个流程跑一遍最后把每个流程记录为一个interactiveChecks条目是强过程是施工图。在强过程面前你没法偷懒因为做完的标准不是我觉着做完了而是一张写满了是/否的、客观的Checklist。第九章7个里程碑的实战——从地基到封顶理论讲完了我们来看看这30个小时里这条流水线到底经历了什么。里程碑内容断言数返工轮数m1-foundation地基认证、社区、员工、楼栋、住户1033轮m2-customer-service客服报修、投诉、收费、通知、调查512轮m3-infrastructure设施维护设备、巡检、维修、电梯672轮m4-cleaning保洁计划、任务、记录、消毒301轮通过 ✨m5-security安保值班、巡逻、门禁、突发事件302轮m6-greening绿化资产、养护、水景、健康告警212轮m7-integration总装集成跨模块事件、仪表盘、API172轮总计319平均2轮mission-planning.md还规定了一个里程碑封存机制“Once a milestone’s validators pass, it is sealed. Never add to a completed milestone.”一旦验收通过立刻封存永不修改。就像建筑验收地基验收通过后盖了章你就不能再在上面打洞了。这保证了系统的稳定性是单向递增的不会出现修一个bug搞崩三个老功能的经典场面。M1最痛苦的地基。认证、用户、权限是所有功能的基础也是最复杂的。它花了3轮才通过。第一轮修API规范第二轮修表单逻辑。全程AI自己诊断、自己修、自己复测。M3精准的手术。在设施维护模块代码审查员发现了4个致命问题包括一个DELETE请求返回了错误的HTTP状态码和一个潜在的SQL注入漏洞。修复过程是外科手术式的只改了78行删了29行没碰其他地方。M4模式的胜利。保洁模块30个断言一轮通过。为什么因为它的业务模式Plan-Task-Record在M1到M3里已经被反复捶打成熟了。到了M4只是换了个保洁的业务皮核心逻辑稳如老狗。这就是抽象和复用的力量。M7最终的验收。最后一步是集成测试验证跨模块的联动。比如“创建一个报修单是否能自动创建一个维修工单”、“业主A的通知业主B能不能看到”。7个步骤验证了数据隔离的各个维度这在很多人类项目中都是直接被忽略的。第十章双重质检员——代码审查员与用户测试员让我们把镜头拉近看看两个守护进程是如何工作的。1. 代码审查员 (scrutiny-validator)它的流程极其务实第一步不审则废。如果连基本的类型检查(typecheck)或代码风格检查(lint)都过不了它会直接打回根本不会浪费算力去做更高级的人工审查。第二步并行审查。它会为每个功能模块启动一个子Agent同时审阅代码速度快得惊人。第三步三级知识分流。这是最有智慧的设计。当审查员们发现了有价值的信息它会进行分类处理可以直接应用的事实性知识比如某个API的URL是/api/xxx审查员自己更新到知识库。需要确认的规范性决策比如我们以后应该统一用这种错误处理方式它只作为建议提交给人类自己不越权修改。模糊、重复、无用的信息直接丢弃。这个分流的哲学是事实知识可以自动积累但改变规则的权利必须留给人类。它承认了AI的边界这是一种成熟。2. 用户测试员 (user-testing-validator)它的核心是动态并发控制。它不是一个能跑几个跑几个的莽夫而是一个精算师。它执行一个四步决策读取规划阶段算好的最大理论并发数。实时检测你电脑当前的CPU和内存负载。分析哪些测试会互相干扰比如共用同一个测试账号的必须串行。取三者理论值、当前负载、隔离要求的最小值作为最终同时跑几个测试的决定。而且它会在启动子Agent之前提前把隔离环境准备好创建好独立的测试账号、数据目录、端口然后直接把一个干净的环境交给子Agent。子Agent不需要操心环境问题拿到手就能用。知识不是靠自觉积累的是靠系统自动提取的。终章数据冲击与新范式的黎明现在让我们把所有数字摆在一起感受一下冲击力。指标数值总交付文件数208个内置技能文件数5个项目总里程碑7个验证断言总数319个单元/集成测试用例900个代码审查报告数25份测试证据文件数50份总运行时长30小时人类干预次数0次发现并修复的严重问题4个一轮通过的里程碑1个在数字背后是这套系统沉淀下来的设计原则用3个强制确认点锁定人类决策的边界。用强制Dry Run在编码前验证环境。用70%余量法则保障系统稳定性。用Baseline基线验证确保不在废墟上施工。用禁止管道来守护测试结果的真实性。用里程碑封存来保证质量的单向累积。用三级知识分流来界定AI自动化与人类决策的边界。用对抗性Handoff设计来对抗AI的执行惰性。这不是一个会写代码的AI。这是一个有BIOS基本输入输出系统、有守护进程、有内存管理、有权限控制、有知识自举机制的自动化软件工厂。写给你这套模式对你意味着什么如果你是独立开发者你有没有过这样的体验一个好点子光搭个登录注册的架子就耗掉了所有热情。Droid Mission 告诉你你可以把你的开发规范写成.skill文件把你的业务知识沉淀到library/然后让Agent去执行。你来做架构师它来做施工队。如果你是技术管理者你是否受够了团队里代码质量参差不齐全靠骨干加班Review319个断言和900个测试用例是系统的兜底条款。代码质量的上限不取决于你团队里最强的那个10x程序员而取决于最弱的一环有没有被系统兜住。如果你是产品经理你是否常常困惑为什么我提的是一朵花开发给我的却是一坨泥这套系统的强过程理念可以救你。别再写开发一个用户管理页面了试着写“1. 先写测试覆盖渲染、校验、提交、错误四种场景。2. 用自动化浏览器跑通所有流程。3. 每个流程都必须有完整的交互检查记录。”把愿景翻译成施工图交付物才能不跑偏。如果你只是一位技术观察者我想告诉你我们正站在一个巨大的范式转移的门口。这不是AI写代码的小打小闹这是对软件开发这件事本身的重新定义。人类的经验、规范、知识被编码为操作系统而AI Agent在这个系统上以人类无法比拟的纪律性和耐力在执行。这不是在替代程序员这是在升级整个行业的操作系统。几条金句送给读完这篇文章的你“代码质量的上限不取决于最强的那个人能写多好而取决于最弱的那一环有没有被兜住。”319个断言900个测试就是那个兜底的网。这张网不是靠某个人的责任心织的是系统强制铺开的。“弱过程和强过程的区别不在于谁规定得更细而在于谁有权定义’做完了’。”把定义权交给执行者得到的是惊喜或惊吓。把定义权留给设计者得到的是可预期的确定性。“验证不是工人的美德是流水线上的关卡。”当质量从个人意愿变成系统机制软件工程才真正有了工程的样子。“宁可让输出又长又烦也不允许一个失败的测试混在成功里。”这句话是对所有质量保证工作的最高致敬。“事实性知识可以自动沉淀但改变规则的权利必须留在人类手里。”这是我在所有AI工具里见过的最清醒、最克制的设计哲学。它知道自己的边界在哪。如果你觉得这篇文章对你有所启发欢迎分享给那些还在996-改bug-997-改bug的循环里挣扎的朋友们。也许是时候用一种全新的方式来建造软件了。完