代码工厂夜未眠：我让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当成工厂里的工人。

你想想丰田的工厂是怎么造车的：

1. 建厂房：水、电、气、传送带全部就位。
2. 写手册：每个工位的标准作业程序（SOP）写得清清楚楚。
3. 培训工人：每个工人只负责一个环节，但要做到极致。
4. 流水线作业：一辆车从底盘到总装，经过几十个工序，每个工序都有严格的质量检查。
5. 质检与返工：不合格？立刻下线返修，修完再从这个工位开始走。
6. 总装验收：所有零件组装完，还要最后跑一圈测试场。

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个Phase，3个强制人类确认的检查点 │ ├─────────────────────────────────────────────────┤ │ 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的权责边界画得非常清楚。

人类只在三个地方被要求介入：确认做什么（里程碑）、确认在哪做（基础设施）、确认怎么做（凭证）。这三件事一旦敲定，后续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步上岗流程，一步都不能跳：

1. 读取上下文：并行读取任务书、架构图、服务配置等。
2. 初始化环境：运行init.sh（反正它是幂等的，跑不坏）。
3. 基线验证：跑一遍全量测试，确认当前的环境是健康的。
4. 理解上下文：看看同里程碑下其他功能是怎么做的。
5. 查阅知识库：看看前人留下了什么"坑"。
6. 在线调研：遇到没见过的技术，先上网查，别瞎写。
7. 启动服务：按依赖顺序把数据库、后端、前端都拉起来。

第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的天性就是倾向于生成"看起来合理但经不起推敲"的文本。

那怎么办？系统定义了一套"强过程"。

弱过程（给偷懒留足了空间）：

1. Build the UI
2. Test it works
3. Run validators

强过程（让偷懒无处遁形）：

1. Write tests first (red), then implement to make them pass (green). Cover rendering, validation, submit behavior, error display.
2. Verify every user flow withagent-browser.
3. Each flow tested = oneinteractiveChecksentry with the full sequence and end-to-end outcome.
4. Runnpm run typecheckandnpm run lint.

区别在哪？弱过程把"什么叫做好了"的定义权交给了执行者，强过程把定义权牢牢握在设计者手里。

"开发一个用户管理页面"是弱过程，是愿景。
"先写测试，覆盖渲染、校验、提交、错误处理四种场景，再用agent-browser把每个流程跑一遍，最后把每个流程记录为一个interactiveChecks条目"是强过程，是施工图。

在强过程面前，你没法偷懒，因为"做完"的标准不是"我觉着做完了"，而是一张写满了是/否的、客观的Checklist。

第九章：7个里程碑的实战——从地基到封顶

理论讲完了，我们来看看这30个小时里，这条流水线到底经历了什么。

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)
它的核心是动态并发控制。它不是一个"能跑几个跑几个"的莽夫，而是一个精算师。它执行一个四步决策：

1. 读取规划阶段算好的"最大理论并发数"。
2. 实时检测你电脑当前的CPU和内存负载。
3. 分析哪些测试会互相干扰（比如共用同一个测试账号的必须串行）。
4. 取三者（理论值、当前负载、隔离要求）的最小值，作为最终同时跑几个测试的决定。

而且，它会在启动子Agent之前，提前把隔离环境准备好（创建好独立的测试账号、数据目录、端口），然后直接把一个干净的环境交给子Agent。子Agent不需要操心环境问题，拿到手就能用。

知识不是靠自觉积累的，是靠系统自动提取的。

终章：数据冲击与新范式的黎明

现在，让我们把所有数字摆在一起，感受一下冲击力。

在数字背后，是这套系统沉淀下来的设计原则：

• 用3个强制确认点锁定人类决策的边界。
• 用强制Dry Run在编码前验证环境。
• 用70%余量法则保障系统稳定性。
• 用Baseline基线验证确保不在废墟上施工。
• 用禁止管道来守护测试结果的真实性。
• 用里程碑封存来保证质量的单向累积。
• 用三级知识分流来界定AI自动化与人类决策的边界。
• 用对抗性Handoff设计来对抗AI的执行惰性。

这不是一个"会写代码的AI"。这是一个有BIOS（基本输入输出系统）、有守护进程、有内存管理、有权限控制、有知识自举机制的自动化软件工厂。

写给你：这套模式对你意味着什么？

如果你是独立开发者：你有没有过这样的体验？一个好点子，光搭个登录注册的架子就耗掉了所有热情。Droid Mission 告诉你，你可以把你的开发规范写成.skill文件，把你的业务知识沉淀到library/，然后让Agent去执行。你来做"架构师"，它来做"施工队"。

如果你是技术管理者：你是否受够了团队里代码质量参差不齐，全靠骨干加班Review？319个断言和900个测试用例是系统的"兜底条款"。代码质量的上限，不取决于你团队里最强的那个10x程序员，而取决于最弱的一环有没有被系统兜住。

如果你是产品经理：你是否常常困惑，为什么我提的是"一朵花"，开发给我的却是"一坨泥"？这套系统的"强过程"理念可以救你。别再写"开发一个用户管理页面"了，试着写：“1. 先写测试，覆盖渲染、校验、提交、错误四种场景。2. 用自动化浏览器跑通所有流程。3. 每个流程都必须有完整的交互检查记录。”把愿景翻译成施工图，交付物才能不跑偏。

如果你只是一位技术观察者：我想告诉你，我们正站在一个巨大的范式转移的门口。这不是"AI写代码"的小打小闹，这是对"软件开发"这件事本身的重新定义。人类的经验、规范、知识被编码为"操作系统"，而AI Agent在这个系统上，以人类无法比拟的纪律性和耐力在执行。

这不是在替代程序员，这是在升级整个行业的"操作系统"。

几条金句，送给读完这篇文章的你

“代码质量的上限，不取决于最强的那个人能写多好，而取决于最弱的那一环有没有被兜住。”
319个断言，900个测试，就是那个兜底的网。这张网不是靠某个人的责任心织的，是系统强制铺开的。

“弱过程和强过程的区别，不在于谁规定得更细，而在于谁有权定义’做完了’。”
把定义权交给执行者，得到的是惊喜或惊吓。把定义权留给设计者，得到的是可预期的确定性。

“验证不是工人的美德，是流水线上的关卡。”
当质量从"个人意愿"变成"系统机制"，软件工程才真正有了"工程"的样子。

“宁可让输出又长又烦，也不允许一个失败的测试混在成功里。”
这句话是对所有质量保证工作的最高致敬。

“事实性知识可以自动沉淀，但改变规则的权利，必须留在人类手里。”
这是我在所有AI工具里见过的最清醒、最克制的设计哲学。它知道自己的边界在哪。

如果你觉得这篇文章对你有所启发，欢迎分享给那些还在"996-改bug-997-改bug"的循环里挣扎的朋友们。

也许是时候，用一种全新的方式，来建造软件了。

（完）