Mar

洞见：TAES 回答"谁托举谁"，MAR 回答"怎么托举"，两者是洞见的递进。

战略定位

我们解决什么问题？

E队（客户团队）面临两个核心障碍：

1. 到不了 — 物理/合规上无法访问全球 AI 服务
2. 用不起 — 经济/技术上无法负担顶级 AI 能力

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 是什么？

TeamsEdge 是 T营 的协力软件——承载"T营 协力 E队"这一关系的数字化平台。

何时使用此技能

何时不使用此技能

TAES 核心概念

四字映射总览

关键洞察：T 和 E 是组织实体，A 是连接两者的能力桥梁，S 是价值飞轮。

S 的本质：三层飞轮

Scale 不是单一指标，而是三层递进的增长引擎。

┌─────────────────────────────────────────────────────────────┐
│  1️⃣ Mission 飞轮（价值层）                                  │
│     发掘 AM → 用 Repo 实现 → 加速完成 + 提升品质            │
├─────────────────────────────────────────────────────────────┤
│  2️⃣ 能力飞轮（学习层）                                      │
│     不断尝试 → 队员 AI 能力 ↑ + E队 协同力 ↑                │
├─────────────────────────────────────────────────────────────┤
│  3️⃣ 规模飞轮（扩展层）                                      │
│     能力沉淀 → 实践规模扩展 → 回归更多 AM                   │
└─────────────────────────────────────────────────────────────┘

托举效应（A = Augment）

托举 = 让 E队 的生产力基于可依赖的基础设施运转。

托举效应 = 网络可靠 × AI可用
           (bit)      (Token)
              ↓
      乘法关系，缺一则归零

网络可靠（bit 可靠 / Workplane）：

• E队 的每一个请求都经由 T营 合规通道到达目标
• IPv6/56 固定出口确保业务 IP 白名单长期有效
• Function 智能分流，按场景选择最优路径
• 网络中断 ≠ 业务中断，冗余设计保障连续性

AI可用（Token 可用 / AITa）：

• Allied AI 托管：E队 无需自建 API Key 管理
• LLM 特性传承：Prompt 模板、上下文窗口、输出格式跨版本兼容
• 常年支付稳定：T营 统一付费，E队 按需消费，无断供风险
• 季度能力更新：Frontier Model 每季评估，始终使用当季最强

Allied AI（协同 AI）定义

Allied = 盟友：不是"人工智能"，而是"盟友智能"——AI 与人类站在同一战线，共同完成 Mission。

三维度定义：

2023-2027 演进路径：

💡 核心洞见：Allied AI 不是 E队 的工具，也不是替代 E队 的成员，而是重新定义了 E队 本身。

E队 = 人 + Allied AI = 智慧协同团队

这不是"人用 AI"，而是"人与 AI 共同构成一个新的组织单元"——边界变了，能力也变了。

协同分工原则：

• 👤 人负责：意图定义 (I)、边界判断 (L)、验收决策 (E)
• 🤖 AI负责：批量执行、模式识别、草稿生成
• 🤝 协同价值 = 人的判断力 × AI 的执行力

季度评估机制：

• Frontier Model 约 6 个月发布重大版本（能力提升 20%+）
• T营 每季度评估更新订阅组合，确保 E队 使用"当季最强"
• 当前参考（2026 Q1）：Claude Opus 4.5 / GPT-5 / Gemini 2.5 Ultra

ICE 三要素（任务执行框架）

ICE = 冰：执行过程像冰块一样清澈、有棱角、可追溯。

💡 口诀：任务要 CLEAR，执行像 ICE 🧊

CLEAR 五要素（AM 任务完整性检查）

AM = Augmented Mission：能被 AI 托举的任务才值得启动。 CLEAR = 清晰：任务定义必须清清楚楚才能启动。

AM 完整性原则：CLEAR 五要素缺一，则任务不可启动；缺 A，则不是 AM。

框架关系：TAES（组织能力）→ CLEAR（任务定义）→ ICE（执行追踪）

Mission vs Task：为什么用 M 而不是 T？

核心洞见：AI 时代，Task 层被 AI 吞噬——你只需定义 Mission，AI 会自动分解并执行 Tasks。

公式含义：M 是乘数。一个空洞的 Task，即使 C² 和 AI 完美，产出的也是空洞的 E。M = 0，则 E = 0。

TeamsEdge 系统架构

菜单结构（9 个 L1）

业务对象三层模型

┌─────────────────────────────────────────────────────────────┐
│  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营角色（服务提供方）

设计原则：轻前台、重系统——人只做"客户界面 + 技术保障"，T 和 S 交给 TeamsEdge。

T营 = 2 人 + TeamsEdge（协力软件）

┌─────────────────────────────────────────────────────┐
│  人                                                  │
│  ├── FDE（客户经理）→ E队 唯一接口，处理 80% 问题   │
│  └── DevOps（工程师）→ L3 火力支援，处理 20% 重技术 │
├─────────────────────────────────────────────────────┤
│  TeamsEdge（协力软件）                               │
│  ├── 管理模块 → 对内：审批流、资源调度、权限管理    │
│  └── 结算模块 → 对外：计费、额度、发票、账单        │
└─────────────────────────────────────────────────────┘

FDE 模式（Field Delivery Engineer）

FDE = 现场交付工程师，T营 客户经理的工作模式。

传统模式 vs FDE 模式：

FDE 的三重身份：

┌─────────────────────────────────────────┐
│  FDE = 销售 + 实施 + 客服               │
│                                         │
│  · 销售思维 → 理解 E队 的业务痛点       │
│  · 实施能力 → 配置 Mission、交付验收    │
│  · 客服意识 → 长期陪伴、持续优化        │
└─────────────────────────────────────────┘

为什么 TAES 需要 FDE？

• 托举的本质是服务：E队 消费的不是产品，是"网络可靠 × AI可用"的持续能力
• Mission 需要闭环：从意图（I）到证据（E），需要一个人全程跟进
• 信任靠人建立：E队 的 Don/Yuki 需要一个可信赖的 T营 接口人

FDE 技能画像

优先招聘画像：

• ⭐ 有技术支持/运维背景（懂排障思维）
• ⭐ 曾在 E队 工作过（懂用户视角）
• ⭐ 有社区运营经验（懂长期关系）

人才来源路径：

核心原则：不招"有证书的人"，招"能让 E队 成功的人"。

FDE 能力分层（L1/L2/L3）

80/20 原则：FDE 独立处理 80% 的问题（L1+L2），仅 20% 升级给工程师。

升级机制

配比参考

配比弹性：取决于 E队 的 Mission 复杂度和自治能力。引导师（Yuki）强的团队，FDE 负担更轻。

E队角色（服务消费方）

E队治理结构：Don（方向）→ Ilya（技术）→ Yuki（执行）→ 队员（产出）

协作触点

开发实践指南

新增/修改菜单项

1. 定位 TAES 归属 → 该功能属于 T/A/E/S 哪个维度？
2. 参考 Main.md   → 现有 L1→L2→L3 结构是什么？
3. 确认权限边界   → T营 还是 E队 操作？
4. 输出标准 Issue → 使用 @issue-atp 模式

新增业务对象（Entity）

1. 判断对象类型   → Principals / Assets / Capabilities
2. 参考 Entities/ → 复用已有模板
3. 术语对齐       → 中英文与 TAES 体系一致

ATP 视图开发

ATP = Attention Table Page（注意力表格页，TeamsEdge 主界面）

1. 明确 ATP 编号  → 如 ATP-1600（E队列表页）
2. 分析变更范围  → 属性列 / Context 提示 / 子列表
3. 双层验收      → UI 验收 + 逻辑验收

品控检查清单

图例：✅ 可自动化 | ⚪ 可辅助 | ❌ 纯人工

🔗 相关技能

💡 口诀：框架用 MAR，启动用 CLEAR，执行用 ICE 🧂

MAR (I know)      →    CLEAR (I plan)    →    ICE (I do)
 战略层                 任务层                执行层
理解框架            定义任务              追踪执行