夜雨聆风AI写代码之后，最先变快的是个人。但真正难的是让这段代码通过review、跑过CI/CD、部署到生产环境，并且安全、稳定、高效地运行。
现在已经不是“少数人试试AI写代码”的阶段了。
SonarSource的2026 State of Code调查里，开发者报告自己提交或贡献的代码中，平均有42%由AI生成或显著辅助，他们还预计这个比例到2027年会升到65%。这个数据来自开发者自报，不等于每个团队的真实占比。但从日常使用看，实际比例只会更高，而且还会继续上升。
同一份调查里还有一个细节：96%的开发者并不完全信任AI生成代码的正确性，却只有48%每次提交前都会检查。生成在加速，验证却没跟上。
一个接口、一个脚本、一个测试用例，甚至初始化一个项目，AI用几分钟就完成了。但用得多了之后，就会发现AI会忘事。
它可能刚刚修过同类问题，换个文件又犯一次；你指出它的错误，它后面还会重复犯；它也可能顺手做要求外的改动，把一个小需求扩展成无关重构。更常见的是，它不知道什么时候该停，代码生成了就宣布完成。
这不只是prompt没写好。AI Agent的可靠性本身，仍然是一个没有完全解决的问题。
比如Terminal-Bench 2.0把Agent放到真实终端环境里完成长链路任务，论文里最强的模型加Agent组合也只解决了约63%的任务。另一个关于SWE-Bench的研究UTBoost指出，原有测试可能过窄，存在“补丁通过测试，但并没有真正解决问题”的情况，补齐这些测试后，SWE-Bench Verified上约24%的排行榜结果发生了变化。
这些测试不等同于真实团队交付，但它们提醒了同一件事：能生成代码，和能可靠交付软件，是两件不同的事。
问题不是工具不够新
我们已经在用业界最前沿的编程工具和模型了，也给项目加了不少rules和skills，让AI知道代码规范、目录结构、测试要求和常见注意事项。
这些约束有帮助，但还不够。
不得不提下大语言模型本身的局限性：在概率上生成下一个token，天然可能出错；上下文窗口有限，长任务里早期约束容易被冲淡；注意力也不是稳定的工程记忆，重要信息可能在多轮修改后被忽略。
所以AI还是会忘事情。它会忘记刚刚确认过的约束，会重复犯类似错误，会把review意见只修一半，也会在没有完成验证时提前收工......
这让我意识到，问题不只是“再换一个更强的模型”。真实的软件交付不是靠某个人手快完成的，而是靠角色分工、工程规范、质量准则和经验沉淀共同完成的。
我真正想解决的问题变成了：怎样把AI助手打造成一支稳定输出生产级任务的团队，让它遵守软件工程的最佳实践？
于是便有了AI Crew。
为什么自己实现
市面上已经有一些多Agent方案，比如MetaGPT这类框架，会把需求、设计、开发、测试拆成多个角色。这些项目给了我很多启发，但最后我还是选择自己做一套更小、更贴近自己流程的实现。
原因很现实。
通用多Agent框架面向大部分场景，功能比较完善，但通用性高导致定制化成本更高。对已有工程团队来说，真正难的是把既有规范放进系统里，而且不断修改优化的代价不低。
比如代码规范、PR规则、CI/CD流程、安全准则、review习惯、项目记忆，都要能被Agent直接读取和执行。我们需要的不是一个“看起来像虚拟公司”的复杂系统，而是一套能落到日常开发里的工程约束。
所以我的目标不是做一个最大化通用的平台，而是做一支可控、贴近实际交付链路的AI工程团队。
AI Crew是什么
一句话说，AI Crew是一个模拟完整软件工程团队的多智能体系统。
里面有PM、Architect、Developer、Reviewer、QA等角色，也有一个Orchestrator负责协调它们。不同Agent可以使用不同模型：有的更适合规划，有的更适合写代码，有的更适合review，有的更适合测试和查缺补漏。模型能力不是平均分配，而是按任务类型使用。
但AI Crew的重点不是“有很多Agent”。多个Agent堆在一起，并不会自然变成团队。
真正关键的是三件事：
角色即规范。
流程即约束。
记忆即进化。
角色即规范
在AI Crew里，每个角色都是一份可执行的工程契约。它不只是描述身份，而是写清楚职责边界、行为准则、验收标准和失败处理方式。
以Developer为例，它不是简单地“按照设计写代码”。它的职责是以架构设计为指引实现功能，但不能盲从设计。
如果实现过程中发现设计有问题，Developer不能默默偏离设计，也不能硬着头皮执行一个明显走不通的方案。它必须把问题上报给Orchestrator，由协调者决定是否回到架构阶段。
我把这种行为叫作“批判性服从”。
它既避免Agent擅自发挥，也避免Agent机械执行。软件工程里很多质量问题，不是因为没人会写代码，而是问题在角色边界处被悄悄吞掉了。
Developer还有严格的实施纪律。动手前要读已审批的设计文档、项目上下文、现有代码和编码标准。实现时采用增量切片：实现一个切片，测试，验证，再继续下一个切片。
它也会被要求优先做风险最高的部分，优先打通一条完整路径，优先定义接口契约。这样可以尽早暴露不确定性，而不是最后堆出一个很大的未验证提交。
还有一个我很在意的细节：验证结果不能用“全部通过”来概括。
Agent必须提交逐字复制的终端输出，包括lint、format check、type check、tests等命令的结果。因为在实际使用中，“我已经验证过了”这句话太容易变成幻觉式报功。只有原始输出，才是可审计的。
流程即约束
AI Crew不是让多个Agent自由聊天、看起来很热闹。
它有一条明确的SDLC（Software Development Life Cycle，软件开发生命周期）链路：需求、架构、计划、实现、修复、持续验证、发布。每个阶段都有准入条件和退出条件。
比如/prd工作流会先确认需求，再写PRD，最后经过review，确保任务不是一段模糊描述，而是一组可验证目标。
再比如/arch工作流会由Architect根据PRD生成架构设计方案，再经过Architect group review，最后提交PR让人review。架构不是Agent自己说了算，而是要经过明确的设计和审查过程。
这套流程看起来比直接让AI写代码慢。
但它解决的是另一个问题：交付不是完成代码，而是将变更成功部署到生产环境。
这意味着代码要能部署、能监控、能回滚，安全边界清楚，性能没有明显退化，测试覆盖关键路径。
流程约束的意义，就是把这些要求提前放进Agent的工作定义里。
记忆即进化
记忆这一层，决定了AI Crew能不能越用越好。
所以我把记忆分成三层：事实、经历、学习。
事实指必须和权威来源保持一致的信息，比如第三方API Spec、安全策略、公司合规要求。事实只能从权威来源同步，AI不能自己改写或润色。
经历是原始上下文记录。哪个Agent在什么时候做了什么，review指出了什么问题，QA复现了什么bug，最后怎么修掉。这部分不让AI压缩，因为压缩会丢上下文。
学习是从事实和经历里提炼出的可执行规则，最终要落到系统行为里。
比如某次Developer在安全模块里忘了密码哈希加盐。这个经历本身会被保留。之后系统可以从多次类似经历中总结出一条可执行规则：安全相关模块实现前，Developer必须显式列出要遵循的安全规则清单，否则不能开始编码。
这条规则最后会进入Developer的角色指令或安全检查规则里。下一次再做类似任务，Agent不是“想起了一个故事”，而是它的行为约束已经改变了。
第一次做项目时，系统只有通用规则。做得多了之后，它会积累团队自己的规范、常犯错误、技术栈偏好、review重点和项目特定知识。更好的规则减少低级错误，低级错误减少后，学习就能集中在更高层的问题上。
系统不是每次从零开始，而是在过去的经验上继续工作。
最后
这套方式也有局限。
一是简单任务可能被复杂化，修一个拼写错误不需要PM、架构师、开发、review和QA全流程跑一遍；
二是token消耗会变大，多个Agent读上下文、写计划、互相review，本质上是在用更多上下文换更强的过程约束。
这就要求Orchestrator判断任务大小。低风险任务走轻流程，高风险任务才启动完整Crew。
在我看来，AI编程工具的关键能力会从“生成更多代码”，逐步转向“稳定可靠地完成工程任务”：理解约束，保留上下文，执行验证，在不确定时升级给人处理。
代码只是交付的一部分。真正的工程能力，是把一段变化稳定地带到生产环境里。
SonarSource的2026 State of Code调查https://www.sonarsource.com/state-of-code-developer-survey-report.pdf
Terminal-Bench 2.0 https://arxiv.org/html/2601.11868v1
UTBoost https://aclanthology.org/2025.acl-long.189/
