name: MAR description: MAR 仓库战略指南。用于理解 TAES 框架、E=MC²AI 公式、TeamsEdge 菜单设计、业务对象建模。任务定义请用 CLEAR Skill，执行追踪请用 ICE Skill。

MAR 仓库战略指南

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队（客户团队）面临两个核心障碍：

到不了 — 物理/合规上无法访问全球 AI 服务
用不起 — 经济/技术上无法负担顶级 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队"这一关系的数字化平台。

何时使用此技能

场景	典型任务
🎯 菜单设计	新增/优化 TeamsEdge L1→L2→L3 菜单结构
📋 业务建模	定义主体、资产、能力三层业务对象
🖥️ 界面规划	设计 ATP（注意力表格页）视图布局
📝 需求转化	将业务需求拆解为可执行的开发 Issue
✅ 验收设计	制定 Pass/Fail 可判定的验收标准

何时不使用此技能

场景	原因	替代方案
🚫 纯前端样式	不涉及业务逻辑	使用通用 UI 技能
🚫 底层基础设施	超出 CRUD 范围	使用 DevOps 技能
🚫 非 TeamsEdge 项目	TAES 术语不适用	使用项目专属技能
🚫 财务/法务合规	需专业领域知识	咨询专业顾问

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 是价值飞轮。

S 的本质：三层飞轮

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

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

飞轮	驱动力	产出	TeamsEdge 落地
Mission	AM 完成率	交付物 + 客户价值	Mission + Foundry
能力	实践频次	团队成长 + 方法论	AI Intelligence
规模	能力复用	更多 E队 + 更多 AM	Credits & Billing

托举效应（A = Augment）

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

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

本质	品牌术语	组件	业务承诺
网络可靠	bit 可靠	Workplane	合规通道 · 固定出口 · SLA 保障 · 7×24 运维
AI可用	Token 可用	AITa	LLM 特性传承 · 常年支付稳定 · 季度能力更新

网络可靠（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。

三维度定义：

维度	门槛	验收方式	深层含义
质量	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 共同构成一个新的组织单元"——边界变了，能力也变了。

协同分工原则：

👤 人负责：意图定义 (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 = 冰：执行过程像冰块一样清澈、有棱角、可追溯。

要素	含义	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 🧊

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

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（执行追踪）

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

核心洞见：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。

TeamsEdge 系统架构

菜单结构（9 个 L1）

#	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营角色（服务提供方）

设计原则：轻前台、重系统——人只做"客户界面 + 技术保障"，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 模式（Field Delivery Engineer）

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

传统模式 vs FDE 模式：

维度	传统模式	FDE 模式
角色分工	销售 → 实施 → 客服（多人接力）	一人负责全周期
沟通成本	E队找不同人解决不同问题	E队只认一个人
交付闭环	销售不懂技术，技术不懂客户	既懂业务又能交付
客户关系	签单即结束	客户成功才算成功

FDE 的三重身份：

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

为什么 TAES 需要 FDE？

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

FDE 技能画像

类型	技能	验证方式
必备	MR 工作法（Repo 级交付）	独立完成 1 个 E队的 Mission 交付
必备	协同力	试用期 E队满意度 ≥ 80%
加分	GH900 / Copilot 认证	有则优先，无则入职后培训

优先招聘画像：

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

人才来源路径：

阶段	策略	FDE 来源
0→1	创始团队自己当 FDE	内部
1→10	从成功 E队中选拔"毕业生"	E队 → T营
10→N	外部招聘 + 内部培训体系	混合

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

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

层级	问题类型	处理者	典型场景
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 负担更轻。

E队角色（服务消费方）

角色	代号	职责定位	权限范围
案主	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 模式

新增业务对象（Entity）

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

ATP 视图开发

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)
 战略层                 任务层                执行层
理解框架            定义任务              追踪执行

Name	mar
Description	MAR 仓库战略指南。用于理解 TAES 框架、E=MC²AI 公式、TeamsEdge 菜单设计、业务对象建模。任务定义请用 CLEAR Skill，执行追踪请用 ICE Skill。

mar

SKILL.md