MAR 仓库战略指南。用于理解 TAES 框架、E=MC²AI 公式、TeamsEdge 菜单设计、业务对象建模。任务定义请用 CLEAR Skill,执行追踪请用 ICE Skill。
MAR: Mission Augmented Repo(使命·增强·仓库)
TAES 口号: 協力營托举E队——AI真干活
MAR 口号: AI 托举执行,Mission 由你驾驭
时代锚点: 这不是未来。这是 2026。理论基础: TAES 框架(TeamsCamp Augments EdgeTeams Scale)
核心公式: $E = MC^2 \times AI$ — 价值 = 使命 × 连结 × 语境 × 协同智能
版本: v2.0 | 更新日期: 2026-01-19 | 维护者: @taes
┌─────────────────────────────────────────────────────────┐
│ TAES — 组织层(谁托举谁) │
│ "協力營托举E队——AI真干活" │
├─────────────────────────────────────────────────────────┤
│ MAR — 任务层(怎么托举) │
│ "AI 托举执行,Mission 由你驾驭" │
├─────────────────────────────────────────────────────────┤
│ 共享时代锚点 │
│ "这不是未来。这是 2026。" │
└─────────────────────────────────────────────────────────┘
洞见:TAES 回答"谁托举谁",MAR 回答"怎么托举",两者是洞见的递进。
E队(客户团队)面临两个核心障碍:
T营(協力營)的价值主张:
通过 托举效应,让 E队 在有限预算内获得"原本不可及"的 AI 能力,
使 人的判断力 × AI 的执行力 成为可能。
E=MC²AI 与 TAES 是同一价值创造过程的两种表达。
E = MC²AI (MAR 架构公式) TAES (运营公式)
║ ║
╠══ M (Mission) ←────────→ S 的核心载体
║ ║
╠══ C¹ (Connection) ←────────→ A 的基础设施 (Workplane + AITa)
║ ║
╠══ C² (Context) ←────────→ AI 的上下文 (3W+1H 语境)
║ ║
╠══ AI (Allied AI) ←────────→ A 的托举效应
║ ║
╚══ E (Empower) ←────────→ E队产出 + S增长飞轮
T营 持有基础设施 → 托举 E队 使用 AI → E队 产出 Mission 交付物 → 价值闭环
TeamsEdge 是 T营 的协力软件——承载"T营 协力 E队"这一关系的数字化平台。
| 场景 | 典型任务 |
|---|---|
| 🎯 菜单设计 | 新增/优化 TeamsEdge L1→L2→L3 菜单结构 |
| 📋 业务建模 | 定义主体、资产、能力三层业务对象 |
| 🖥️ 界面规划 | 设计 ATP(注意力表格页)视图布局 |
| 📝 需求转化 | 将业务需求拆解为可执行的开发 Issue |
| ✅ 验收设计 | 制定 Pass/Fail 可判定的验收标准 |
| 场景 | 原因 | 替代方案 |
|---|---|---|
| 🚫 纯前端样式 | 不涉及业务逻辑 | 使用通用 UI 技能 |
| 🚫 底层基础设施 | 超出 CRUD 范围 | 使用 DevOps 技能 |
| 🚫 非 TeamsEdge 项目 | TAES 术语不适用 | 使用项目专属技能 |
| 🚫 财务/法务合规 | 需专业领域知识 | 咨询专业顾问 |
| 字母 | 角色 | TeamsEdge 菜单 | 核心职责 |
|---|---|---|---|
| T | TeamsCamp(協力營) | 2. TeamsCamp | 资源持有方:合同主体、算力池、授权分发 |
| A | Augment(托举) | 3. Augment | 能力放大器:网络可靠 × AI可用 |
| E | EdgeTeams(E队) | 1. EdgeTeams | 价值创造方:团队、角色、Mission、交付 |
| S | Scale(增长) | 4-7 菜单 | 增长飞轮:交付 → 认知 → 结算 → 度量 |
关键洞察:T 和 E 是组织实体,A 是连接两者的能力桥梁,S 是价值飞轮。
Scale 不是单一指标,而是三层递进的增长引擎。
┌─────────────────────────────────────────────────────────────┐
│ 1️⃣ Mission 飞轮(价值层) │
│ 发掘 AM → 用 Repo 实现 → 加速完成 + 提升品质 │
├─────────────────────────────────────────────────────────────┤
│ 2️⃣ 能力飞轮(学习层) │
│ 不断尝试 → 队员 AI 能力 ↑ + E队 协同力 ↑ │
├─────────────────────────────────────────────────────────────┤
│ 3️⃣ 规模飞轮(扩展层) │
│ 能力沉淀 → 实践规模扩展 → 回归更多 AM │
└─────────────────────────────────────────────────────────────┘
| 飞轮 | 驱动力 | 产出 | TeamsEdge 落地 |
|---|---|---|---|
| Mission | AM 完成率 | 交付物 + 客户价值 | Mission + Foundry |
| 能力 | 实践频次 | 团队成长 + 方法论 | AI Intelligence |
| 规模 | 能力复用 | 更多 E队 + 更多 AM | Credits & Billing |
托举 = 让 E队 的生产力基于可依赖的基础设施运转。
托举效应 = 网络可靠 × AI可用
(bit) (Token)
↓
乘法关系,缺一则归零
| 本质 | 品牌术语 | 组件 | 业务承诺 |
|---|---|---|---|
| 网络可靠 | bit 可靠 | Workplane | 合规通道 · 固定出口 · SLA 保障 · 7×24 运维 |
| AI可用 | Token 可用 | AITa | LLM 特性传承 · 常年支付稳定 · 季度能力更新 |
网络可靠(bit 可靠 / Workplane):
AI可用(Token 可用 / AITa):
Allied = 盟友:不是"人工智能",而是"盟友智能"——AI 与人类站在同一战线,共同完成 Mission。
三维度定义:
| 维度 | 门槛 | 验收方式 | 深层含义 |
|---|---|---|---|
| 质量 | Mission 产出通过 Eval 验收 | CLEAR 的 E 判定 | AI 不是"做完",而是"做对" |
| 效率 | 完成时间 ≤ 人类基线 × 50% | 时间戳对比 | AI 不是"能做",而是"快做" |
| 成本 | Token 成本 ≤ 人类市场价 × 10% | 财务核算 | AI 不是"省钱",而是"边际趋零" |
2023-2027 演进路径:
| 年份 | 阶段 | Allied AI 的角色 | 人的角色 |
|---|---|---|---|
| 2023 | 能用 | 听指令干活 | 写 prompt、审产出 |
| 2024 | 好用 | 快速迭代 | 定方向、做验收 |
| 2025 | 普惠 | 边际成本趋零 | 人人可用、按需调用 |
| 2026 | 融合 | 主动理解 Context,补全意图 | 只需表达"想要什么" |
| 2027 | 托举 | 自主发现 Mission,提案执行 | 决策、验收、战略 |
💡 核心洞见:Allied AI 不是 E队 的工具,也不是替代 E队 的成员,而是重新定义了 E队 本身。
E队 = 人 + Allied AI = 智慧协同团队
这不是"人用 AI",而是"人与 AI 共同构成一个新的组织单元"——边界变了,能力也变了。
协同分工原则:
季度评估机制:
ICE = 冰:执行过程像冰块一样清澈、有棱角、可追溯。
| 要素 | 含义 | TeamsEdge 落地 | 验证问题 | 源自 CLEAR |
|---|---|---|---|---|
| I | Intent(意图) | EdgeTeams > Mission > MISSION.md | "想做什么?" | C (Context) |
| C | Condition(条件) | Augment > Workplane + AITa | "条件是什么?" | L (Limit) |
| E | Eval(评估) | Foundry > Artifacts + AI Intelligence | "怎么验收?" | E (Eval) |
💡 口诀:任务要 CLEAR,执行像 ICE 🧊
AM = Augmented Mission:能被 AI 托举的任务才值得启动。 CLEAR = 清晰:任务定义必须清清楚楚才能启动。
| 字母 | 英文 | 要素 | 定义 | 验证方式 | 映射 TAES |
|---|---|---|---|---|---|
| C | Context | 明确输入 | 任务描述与上下文清晰 | MISSION.md 存在且完整 | T (资源) |
| L | Limit | 边界 | 明确"不做什么",防止范围蔓延 | 排除项已列出 | T (资源) |
| E | Eval | 验收标准 | Pass/Fail 可判定 | AC 列表可勾选 | S (增长) |
| A | Augment | AI可托举 | 产出类型在 AI 能力范围内 | Copilot 可执行 | A (托举) |
| R | Result | 价值结果 | 产出物对接收方有价值 | 交付物已归档 Teams/ | E (执行) |
AM 完整性原则:CLEAR 五要素缺一,则任务不可启动;缺 A,则不是 AM。
框架关系:TAES(组织能力)→ CLEAR(任务定义)→ ICE(执行追踪)
核心洞见:AI 时代,Task 层被 AI 吞噬——你只需定义 Mission,AI 会自动分解并执行 Tasks。
| 维度 | Task(任务) | Mission(使命) |
|---|---|---|
| 问的问题 | How(怎么做) | Why(为什么做) |
| 生命周期 | 完成即消亡 | 完成即永生(Repo 是活的) |
| AI 角色 | AI 执行 Tasks | AI 托举 Mission |
| 人的角色 | 分解、监督 | 定义意义、验收价值 |
公式含义:M 是乘数。一个空洞的 Task,即使 C² 和 AI 完美,产出的也是空洞的 E。M = 0,则 E = 0。
| # | L1 菜单 | 中文 | TAES | 一句话定位 |
|---|---|---|---|---|
| 1 | EdgeTeams | E队 | E | 客户是谁?团队、角色、站点 |
| 2 | TeamsCamp | T营 | T | 资源在哪?合同主体、算力池 |
| 3 | Augment | 托举 | A | 如何连接?网络通道、AI托管 |
| 4 | Mission | 使命 | S | 做什么?MR管理、Function |
| 5 | The Foundry | 工坊 | S | 交付什么?CI/CD、静态页 |
| 6 | AI Intelligence | 认知 | S | 学到什么?知识库、Eval |
| 7 | Credits & Billing | 权益 | S | 花了多少?支付、额度、发票 |
| 8 | Notification | 通知 | — | 系统通知、审批流、工单 |
| 9 | System | 系统 | — | 操作员、配置、运维 |
┌─────────────────────────────────────────────────────────────┐
│ Principals(主体层)— "谁在参与?" │
│ ├── TeamsCamp (T营) → 业务主体,持有资产 │
│ └── EdgeTeam (E队) → 操作单元,消费资产 │
├─────────────────────────────────────────────────────────────┤
│ Assets(资产层)— "有什么资源?" │
│ ├── AITC (算力资产) → Frontier Model 订阅,支撑 AITa │
│ └── POP (站点资产) → IPv6/56 出口 + Function,支撑 Workplane │
├─────────────────────────────────────────────────────────────┤
│ Capabilities(能力层)— "怎么识别/连接?" │
│ ├── NexusPass → 身份凭证体系 │
│ ├── EdgeTeam-Code → E队番号体系 │
│ └── EdgeTeam-Domain → 域名服务 │
└─────────────────────────────────────────────────────────────┘
T营(Provider) E队(Consumer)
│ │
│ ──── 托举(A)────→ │
│ │
│ ←── Mission产出(S)── │
设计原则:轻前台、重系统——人只做"客户界面 + 技术保障",T 和 S 交给 TeamsEdge。
T营 = 2 人 + TeamsEdge(协力软件)
┌─────────────────────────────────────────────────────┐
│ 人 │
│ ├── FDE(客户经理)→ E队 唯一接口,处理 80% 问题 │
│ └── DevOps(工程师)→ L3 火力支援,处理 20% 重技术 │
├─────────────────────────────────────────────────────┤
│ TeamsEdge(协力软件) │
│ ├── 管理模块 → 对内:审批流、资源调度、权限管理 │
│ └── 结算模块 → 对外:计费、额度、发票、账单 │
└─────────────────────────────────────────────────────┘
| 类型 | 内部代号 | TAES | 职责边界 |
|---|---|---|---|
| 人 | FDE | E·S | L1 业务 + L2 轻技术,详见 FDE 模式 |
| 人 | DevOps | A | 网络故障、AI 中断、架构变更、安全事件 |
| 系统 | TeamsEdge 管理 | T | 审批流、资源调度、权限管理、E队配置 |
| 系统 | TeamsEdge 结算 | S | 计费、额度、发票、账单 |
FDE = 现场交付工程师,T营 客户经理的工作模式。
传统模式 vs FDE 模式:
| 维度 | 传统模式 | FDE 模式 |
|---|---|---|
| 角色分工 | 销售 → 实施 → 客服(多人接力) | 一人负责全周期 |
| 沟通成本 | E队 找不同人解决不同问题 | E队 只认一个人 |
| 交付闭环 | 销售不懂技术,技术不懂客户 | 既懂业务又能交付 |
| 客户关系 | 签单即结束 | 客户成功才算成功 |
FDE 的三重身份:
┌─────────────────────────────────────────┐
│ FDE = 销售 + 实施 + 客服 │
│ │
│ · 销售思维 → 理解 E队 的业务痛点 │
│ · 实施能力 → 配置 Mission、交付验收 │
│ · 客服意识 → 长期陪伴、持续优化 │
└─────────────────────────────────────────┘
为什么 TAES 需要 FDE?
| 类型 | 技能 | 验证方式 |
|---|---|---|
| 必备 | MR 工作法(Repo 级交付) | 独立完成 1 个 E队 的 Mission 交付 |
| 必备 | 协同力 | 试用期 E队 满意度 ≥ 80% |
| 加分 | GH900 / Copilot 认证 | 有则优先,无则入职后培训 |
优先招聘画像:
人才来源路径:
| 阶段 | 策略 | FDE 来源 |
|---|---|---|
| 0→1 | 创始团队自己当 FDE | 内部 |
| 1→10 | 从成功 E队 中选拔"毕业生" | E队 → T营 |
| 10→N | 外部招聘 + 内部培训体系 | 混合 |
核心原则:不招"有证书的人",招"能让 E队 成功的人"。
| 层级 | 问题类型 | 处理者 | 典型场景 |
|---|---|---|---|
| L1 | 业务问题 | FDE | Mission 配置、账单解释、交付验收、权限申请 |
| L2 | 轻技术问题 | FDE | ATP 调整、Prompt 优化、简单故障排查 |
| L3 | 重技术问题 | 工程师 | 网络故障、AI 服务中断、架构变更、安全事件 |
80/20 原则:FDE 独立处理 80% 的问题(L1+L2),仅 20% 升级给工程师。
| 触发条件 | 升级动作 | SLA |
|---|---|---|
| FDE 判断超出能力范围 | 创建工单 → 工程师 | 4h 响应 |
| E队 明确要求技术支持 | FDE 陪同 → 工程师对接 | 协商 |
| 系统告警(自动) | 直接 → 工程师 | 15min 响应 |
| 阶段 | FDE : E队 | 说明 |
|---|---|---|
| 孵化期 | 1 : 3~5 | 新 E队 需要高频陪伴 |
| 成熟期 | 1 : 10~15 | E队 自运转,FDE 做例行巡检 |
| 规模期 | 1 : 20+ | 系统承载日常,FDE 处理例外 |
配比弹性:取决于 E队 的 Mission 复杂度和自治能力。引导师(Yuki)强的团队,FDE 负担更轻。
| 角色 | 代号 | 职责定位 | 权限范围 |
|---|---|---|---|
| 案主 | Don | 最终决策者,Mission 发起人 | 配置审核、交付签收、费用确认 |
| CTO | Ilya | 技术负责人,架构把关 | 技术方案评审、AI 策略选择 |
| 引导师 | Yuki | 团队领导 + AI 引导 | Mission 分解、质量把控、成员指导 |
| 队员 | — | 任务执行者 | Mission 执行、Artifact 产出、只读配置 |
E队治理结构:Don(方向)→ Ilya(技术)→ Yuki(执行)→ 队员(产出)
| 场景 | T营 | E队 | 交互动作 |
|---|---|---|---|
| 开通服务 | FDE | Don | 配置 → 确认生效 |
| 托举运维 | DevOps | — | 7×24 保障,E队无感 |
| Mission 交付 | FDE | Yuki / 队员 | 产出 → 审核 → 签收 |
| 费用结算 | TeamsEdge(结算) | Don | 系统出账 → 校对确认 |
1. 定位 TAES 归属 → 该功能属于 T/A/E/S 哪个维度?
2. 参考 Main.md → 现有 L1→L2→L3 结构是什么?
3. 确认权限边界 → T营 还是 E队 操作?
4. 输出标准 Issue → 使用 @issue-atp 模式
1. 判断对象类型 → Principals / Assets / Capabilities
2. 参考 Entities/ → 复用已有模板
3. 术语对齐 → 中英文与 TAES 体系一致
ATP = Attention Table Page(注意力表格页,TeamsEdge 主界面)
1. 明确 ATP 编号 → 如 ATP-1600(E队列表页)
2. 分析变更范围 → 属性列 / Context 提示 / 子列表
3. 双层验收 → UI 验收 + 逻辑验收
| # | 检查项 | 验证问题 | 验收方式 | 自动化 |
|---|---|---|---|---|
| 1 | TAES 对齐 | 功能符合 T/A/E/S 定位吗? | 人工审核 | ⚪ |
| 2 | 菜单归属 | L1→L2→L3 路径清晰吗? | 结构验证 | ✅ |
| 3 | 权限正确 | T营 vs E队 权限区分了吗? | 权限矩阵 | ✅ |
| 4 | Evidence | 操作有审计记录吗? | 日志检查 | ✅ |
| 5 | 验收标准 | AC 可 Pass/Fail 判定吗? | Checklist | ⚪ |
图例:✅ 可自动化 | ⚪ 可辅助 | ❌ 纯人工
| 技能 | 定位 | 使用时机 |
|---|---|---|
| MAR | 战略层 | 理解框架、设计菜单、建模对象 |
| CLEAR | 任务层 | 任务启动前的五要素检查 |
| ICE | 执行层 | 任务启动后的追踪留痕 |
💡 口诀:框架用 MAR,启动用 CLEAR,执行用 ICE 🧂
MAR (I know) → CLEAR (I plan) → ICE (I do)
战略层 任务层 执行层
理解框架 定义任务 追踪执行