项目理念

ARM 不是为了让 AI “看起来更聪明”，而是为了让 AI 在长期项目里更稳定、更可协作、更可治理。

今天的大多数 AI 工程，已经能在单轮任务上产出不错的结果；真正困难的部分，出现在任务跨越多轮、多角色、多模块、多天甚至多周之后。这个时候，系统不再只是回答问题，它开始面对组织问题。

一、我们看到的问题

1. 单个 AI session 很难支撑大型项目

大型项目需要同时处理目标、架构、实现、测试、审查、复盘。单个 session 即使能力很强，也很难在有限上下文里长期维持全部视角。

直接后果通常是：

• 角色混杂：既做架构又写实现，还顺手给自己做验收
• 状态丢失：过几轮后没人能准确说明“现在到底进行到哪里”
• 决策漂移：同一个问题在不同回合里得到不同结论
• 证据缺失：出了问题只能翻聊天记录，找不到正式依据

2. 真正的短板不是模型，而是组织能力

很多团队首先会想到换更强的模型、塞更多上下文、写更长的 prompt。这样做有帮助，但解决不了根因。

根因是：AI 缺少可持续的组织结构。

如果一个系统里没有明确角色、正式状态、受约束的写路径和审计链路，那么模型越强，反而越可能在没有边界的前提下做出更多不可追踪的动作。

二、ARM 的核心判断

1. AI 需要角色，不只是提示词

在 ARM 看来，“你现在扮演架构师”这种临时指令远远不够。角色必须具备：

• 明确职责：应该解决什么问题
• 明确边界：不应该越过哪些动作
• 明确输入输出：从哪里拿上下文，产出什么制品
• 明确协作关系：与谁交接、谁来审批、谁来复核

这样做的意义，不是把 AI 变窄，而是让协作可扩展。

2. Runtime 必须承担正式写路径

影响正式项目状态的动作，不能只靠 AI 自己改文件或在对话里宣布完成。ARM 要求这类动作经过受约束的 Runtime 路径，例如：

• 读取当前上下文
• 提出 proposal
• 进行验证
• 获得批准
• 提交或拒绝
• 留下可审计证据

这让“我觉得完成了”变成“系统可证明它为什么完成了”。

3. State 是项目的工作投影

ARM 不把状态理解成一段备注，而是把它理解为项目在当前时刻的正式投影。一个有效的 State，至少应该回答这些问题：

• 当前有哪些工作在进行
• 谁对哪些工作有权限或责任
• 下一步能被什么流程推进
• 已经沉淀了哪些证据、决策和结果

如果这些问题不能被稳定回答，协作规模就很难上去。

4. 协作必须可审计

项目规模一大，真正重要的不只是“有没有做成”，而是：

• 为什么当时做了这个决定
• 依据是什么
• 谁批准了它
• 如果结果有问题，应该回溯到哪一步

ARM 的目标之一，就是让这些问题不依赖人的记忆，而依赖系统的结构。

三、我们的愿景

我们的长期愿景是：

让上下文有限的 AI session，通过组织化协作，像一家公司那样完成超出任何单个 session 能力范围的大型项目。

这个愿景里有三层意思。

1. 人类负责方向，不负责事无巨细地托管

人类像创始人或董事会，负责目标、边界和最终决策。AI 不是替代人类的权威，而是在明确授权和边界下承担专业分工。

2. AI 角色像组织成员，而不是一次性工具

在项目里，架构、开发、测试、审查并不是同一件事。ARM 希望 AI 角色能像团队成员一样分工、交接、互相制衡，而不是共享一个混合身份。

3. 框架本身必须经得起长期运行

我们不是在做一次漂亮的 demo，而是在尝试构建一套能够持续运转、不断演化、可被审计和复盘的协作基础设施。

四、ARM 的基本构架

ARM 当前对外最重要的结构，可以先理解为四层：

1. Meta

最上层是元层。它不描述某个具体项目，而描述“项目应该如何被声明和组织”的基础语法。

2. Profile / Charter

这一层负责把抽象结构落到某种方法论和某个具体项目上。

• Profile 更像可复用模板
• Charter 更像项目自己的组织与规则说明书

3. State

这一层保存项目当前事实，包括工作节点、状态投影、事件、proposal、claim 等运行痕迹。

4. Runtime

Runtime 位于 AI 与项目系统之间，负责：

• 读取角色上下文
• 暴露可用流程
• 约束正式写入动作
• 记录 proposal、commit、reject 与证据

它不是一个“替 AI 做决定”的总控大脑，而是一个事务边界和治理接口。

五、为什么这件事值得关注

1. AI 协作正在从“个人工具”走向“组织系统”

如果 AI 只用于写一段代码、总结一篇文章，普通聊天界面已经足够。但一旦 AI 进入真实的项目、团队和长期工作，就会遇到组织问题。ARM 关注的是这个转折点。

2. 多 AI 协作不能只靠经验主义

现在很多多 AI 系统之所以脆弱，不是因为没有想法，而是因为规则、边界、状态和责任没有被系统化。ARM 想把这些“默认靠经验维持”的部分，变成显式结构。

3. 可治理能力会决定系统能否进入真实场景

公众会关心安全与可靠性，合作方会关心可控、可追溯、可维护。一个只能短期跑通的 AI 系统，很难进入真正重要的组织环境。

六、ARM 当前的工作方式

ARM 项目本身就是 ARM 的第一批使用者。我们坚持一个很朴素的原则：

如果 ARM 连自己的开发过程都治理不好，它就没有资格治理别的项目。

因此我们当前的推进方式是：

• 先在 ARM 自己身上验证角色、流程、Runtime 和状态机制
• 再把有效的方法提炼成更稳定的基础能力
• 在实践中保留设计取舍和复盘证据，而不是只保留最终结论

这也是为什么公开区会讲理念与方向，内部区会继续同步当前进度、当前难点和设计取舍。

七、我们对外公开的承诺

• 尽量把关键方法论写成可执行约束，而不是停留在口号
• 尽量让 AI 工作链路留下证据，而不是只留下结果
• 尽量减少依赖人工记忆的隐式规则
• 尽量用 ARM 自身的运行效果来证明 ARM 是否成立

ARM 仍在演化，但它的方向已经很明确：让 AI 协作从“聪明的对话”升级为“可持续的组织能力”。