Tlyer.Wang

跑记｜备赛第1课 MT10k节奏跑 10km @5:26

Tue, 01 Sep 2026 00:00:00 GMT

半马 Sub145 备赛 · 训练日志 · 第 1 周（适应启动周）

训练日期：2026-08-31（周一）中午｜场地：跑步机（1% 坡度）

计划与执行

计划内容：第 1 周节奏课（周末休息充分后的第一课）

实际执行：跑步机 MT10k，10.00 km 连续节奏跑

COROS 数据

指标	数值
距离	10.00 km
用时	54:26
平均配速	5:26/km（跑步机 11.0 km/h）
卡路里	680 kcal
平均步频	178 spm
平均步幅	1.04 m
爬升	1 m（跑步机）
平均/最高心率	150 / 167 bpm（参考）

当日天气（武汉 · 中午训练时段）

阴转多云，气温约 31℃，相对湿度 45–55%，东北风 3 级，AQI 45（优），无降水。室内跑步机训练，体感良好，无高温高湿干扰。

主观体感

RPE 约 4–5/10：节奏稳定，呼吸可控，可完整说出短句。

教练评价：★★★★☆

配速 5:26/km 落在高驰区间2（有氧功率）上部、逼近区间3 下边界，作为 8 周周期启动课强度恰当——有刺激但不冒进；

步频 178 spm 优秀（高于 170 的高效区间），步幅 1.04 m 稳定，跑姿经济性良好；

10km 匀速无明显掉速，有氧支撑扎实；

作为"周一最硬课"略偏保守（计划周一通常为区间4/5），但周期第一课该保守是对的，速度课从下周一（9/7 区间4 间歇 6×800m）开始上强度。

待改进

节奏课后半程可尝试最后 1–2km 摸进区间3（5:10–5:15），逐步适应阈值附近节奏；

跑步机每 15 分钟补水一次，为后续 90–100 分钟长课建立补给习惯。

半马备赛｜初始状态基线（VO2max49 / 跑力76 / 阈配4:48）

Tue, 01 Sep 2026 00:00:00 GMT

归档日期：2026-08-31（8 周备赛周期第 0 周 / 第 1 周起始）

数据来源：COROS EvoLab 体能评估 + 近 6 个月活动记录（86 次跑步）

用途：作为每周复盘、训练质量评价、竞赛状态追踪的对比基准，所有后续周报均与此快照及上一周状态对比。

一、运动员档案

项目	数值
称呼	阿哲
性别 / 年龄	男 / 39 岁
身高 / 体重	170 cm / 65.5 kg（BMI 22.6）
训练地点	武汉，工作日中午（跑步机为主）
训练窗口	周一至周五中午，每次 ≤ 100 分钟
目标赛事	2026-10-25 半程马拉松
目标成绩	1:45:00（配速 4:59/km · 跑步机 12.0 km/h）

二、体能基线（2026-08-31 快照）

指标	初始值	说明
最大心率（实测）	202 bpm	非年龄估算
静息心率（实测均值）	47–50 bpm	近 30 天区间 47–54
VO₂max	49	EvoLab 评估
跑力值 Fitness Level	76	大众精英，同龄约前 15%
乳酸阈配速	4:48 /km（12.5 km/h）	高驰配速区间锚点
恢复度	85%	良好
训练负荷比 Load Ratio	1.38	Optimized（适中）
身体状况	无伤病记录，状态上升通道	—

三、COROS 比赛预测基线

距离	预测成绩	目标差距
5K	23:07	—
10K	48:18	—
半马	1:49:21	目标 1:45:00，需提升约 4.2%
全马	3:57:05	—

目标可行性：半马配速 4:59 落在高驰区间3（阈值）下半部，约为阈速（4:48）的 96%，属于 8 周周期内"踮脚够得到"的合理目标。

四、近 6 个月跑量基线

月份	月跑量	备注
2026-03	167 km	峰值月之一，含 20km+ 长距离
2026-04	169 km	峰值月
2026-05	145 km	—
2026-06	127 km	—
2026-07	104 km	低谷（单周最低仅 7km）
2026-08	116 km（至 31 日）	回升中

课型构成（近半年）：轻松跑 E 47 次｜节奏跑 M 16 次｜长距离 L 10 次｜间歇 I 8 次｜恢复 R 5 次。

五、教练视角的三个起始问题（改善目标）

轻松跑位置偏快：47 次轻松跑平均 6:07/km ≈ 阈速 80%，卡在高驰区间1/区间2 分界（6:05）；部分"轻松跑"实际进入区间2（5:43–6:00）。→ 周期目标：轻松课严格落在区间1（6:10–6:50）。

长距离断档：最近 20km+ 为 2026-03-07，近 5 个月缺失。→ 周期目标：周五长距离渐进至 17km（含半马配速段）。

负荷波动大：7 月单周最低 7km。→ 周期目标：固定周一/二/四/五四练，周跑量稳定 35–45km。

六、高驰配速区间（强度标尺，全周期唯一强度指标）

高驰区间	配速 /km	跑步机速度	用途
区间1 有氧耐力	6:10–6:50	8.8–9.7 km/h	轻松/恢复/长距离基础段
区间2 有氧功率	5:25–6:05	9.9–11.1 km/h	马拉松配速、长距离加速段
区间3 阈值	4:42–5:24	11.1–12.8 km/h	★半马配速 4:59 / 阈值课 4:45–4:55
区间4 无氧耐力	4:22–4:40	12.8–13.8 km/h	VO2max 间歇
区间5 无氧功率	4:00–4:20	13.9 km/h+	冲刺 / strides

七、周报核心追踪指标（每周复盘时与本基线对比）

指标	基线	追踪方式
VO₂max / 跑力值	49 / 76	COROS 周快照，趋势向上为佳
恢复度	85%	每日 COROS，质量课前应 ≥70%
周跑量 / 计划达成率	约 27km/周（8月）	实际 km ÷ 计划 km
区间3 课完成质量	—	计划配速完成度、掉速幅度
长距离进度	最长 15km（8/26）	每周五距离+末段配速
半马预测成绩	1:49:21	COROS Race Predictor 周变化
静息心率	47–50	连续升高 ≥5 为疲劳预警
训练负荷比	1.38	维持 0.8–1.5，>1.5 警惕
主观恢复/伤病	无	每课自评 + 疼痛记录

*本档案为只读基准，不随周修改；每周复盘生成独立周报文件，指标列与本文件第七节一一对应。*

半马Sub145 · 8周训练计划（高驰乳酸阈配速区间版）

Tue, 01 Sep 2026 00:00:00 GMT

目标：2026-10-25 半马 1:45:00（配速 4:59/km · 跑步机 12.0 km/h）

运动员：阿哲（男，39岁 / 170cm / 65.5kg）｜跑力 76｜VO₂max 49｜乳酸阈配速 4:48/km

安排：周一至周五中午，每次 ≤100 分钟，跑步机为主（1% 坡度）；每周 4 跑 + 2 次核心；周末休息

强度标尺：配速/速度（高驰乳酸阈配速区间），唯一强度指标

一、高驰配速区间（锚点：乳酸阈配速 4:48/km = 12.5 km/h）

高驰配速区间	配速 /km	跑步机速度	训练用途
区间1 有氧耐力	6:10–6:50（恢复日 6:50–7:10）	8.8–9.7 km/h	轻松跑、恢复、长距离基础段，占跑量 60%+
区间2 有氧功率	5:25–6:05（M 配约 5:30）	9.9–11.1 km/h	马拉松配速课、长距离加速段
区间3 阈值	4:42–5:24（阈配 4:48 ★半马配 4:59）	11.1–12.8 km/h	★半马比赛配速、阈值节奏课（核心）
区间4 无氧耐力	4:22–4:40	12.8–13.8 km/h	VO2max 间歇（800m–1km 重复跑）
区间5 无氧功率	4:00–4:20	13.9 km/h 以上	冲刺 / strides 神经激活

中午湿热天按区间内偏慢端执行（慢 3–5 秒/km），不追快。

二、每周固定结构

周一：速度课——区间4 间歇（后期区间5 短冲），一周最硬的课

周二：区间1 轻松跑 + 核心力量 15 分钟

周三：休息（拉伸/泡沫轴）

周四：专项课——区间3 阈值节奏或半马配速 4:59 + 核心力量

周五：长距离——区间1 为主体，后期加区间2/3 加速段，控制在 95–100 分钟

周末：完全休息，补碳水、睡眠 ≥7.5h

核心循环（15′，周二/四跑后）：平板 45″×3 ｜侧桥 30″×2/侧｜臀桥 15×3 ｜单腿硬拉 10×2/侧｜提踵 20×2

三、8 周逐日课表

第 1 周（08/31–09/04）适应启动周

日	区间/课型	训练内容	配速（跑步机速度）	时长
周一	区间2/3 节奏 ✅	MT10k（已完成）	5:26（11.0）	54′
周二	休息	周一课较硬，灵活调整	—	—
周三	休息	完全休息	—	—
周四	区间1 + 区间5	轻松跑 6km，末 4×100m 大步	6:20–6:50；大步 4:10（9.0–9.7 / 14.4）	约45′
周五	区间1 长距离	14km 轻松长跑，末 2km 可到 6:00	6:15–6:40（9.0–9.6）	约90′

第 2 周（09/07–09/11）基础重建周 · 约 38km

日	区间/课型	训练内容	配速（跑步机速度）	时长
周一	区间4 间歇	2km w + 6×800m（间慢 400m/2′30″）+ 2km c	4:25–4:35（13.1–13.6）	约55′
周二	区间1 + 核心	7km 轻松 + 核心 15′	6:20–6:50（8.8–9.5）	约60′
周三	休息	完全休息	—	—
周四	区间3 阈值	2km w + 3×2km（间慢 2′）+ 2km c	4:45–4:55（12.2–12.6）	约62′
周五	区间1 长距离	15km 轻松长跑	6:15–6:40（9.0–9.6）	约95′

第 3 周（09/14–09/18）专项进阶周 · 约 41km

日	区间/课型	训练内容	配速（跑步机速度）	时长
周一	区间4 间歇	2km w + 5×1km（间慢 2′30″）+ 2km c	4:25–4:35（13.1–13.6）	约60′
周二	区间1 + 核心	8km 轻松 + 核心 15′	6:20–6:50（8.8–9.5）	约65′
周三	休息	完全休息	—	—
周四	区间3 半马配速	2km w + 2×3km ★H（间慢 3′）+ 2km c	★4:59（12.0–12.1）	约62′
周五	长距离 1→2	16km：前 12km 区间1，后 4km 区间2	6:20 → 5:30（9.5→10.9）	约98′

第 4 周（09/21–09/25）专项强化周 · 约 42km

日	区间/课型	训练内容	配速（跑步机速度）	时长
周一	区间3 阈值	2km w + 4×2km（间慢 2′）+ 2km c	4:45–4:55（12.2–12.6）	约70′
周二	区间1 + 核心	7km 轻松 + 核心 15′	6:20–6:50（8.8–9.5）	约60′
周三	休息	完全休息	—	—
周四	区间3 半马配速	2km w + 连续 7km ★H + 2km c	★4:59（12.0–12.1）	约58′
周五	长距离 1→3	16km：前 10km 区间1，后 6km ★H	6:20 → 4:59（9.5→12.0）	约97′

第 5 周（09/28–10/02）峰值周（国庆）· 约 45km

日	区间/课型	训练内容	配速（跑步机速度）	时长
周一	区间4 间歇	2km w + 6×1km（间慢 2′30″）+ 2km c	4:25–4:35（13.1–13.6）	约65′
周二	区间1 + 核心	8km 轻松 + 核心 15′	6:20–6:50（8.8–9.5）	约65′
周三	休息	完全休息	—	—
周四	区间3 半马配速	2km w + 2×4km ★H（间慢 3′）+ 2km c	★4:59（12.0–12.1）	约72′
周五	长距离 1→3	17km：前 10km 区间1，后 7km ★H（赛前最长专项课）	6:20 → 4:59（9.5→12.0）	约100′

第 6 周（10/05–10/09）巩固维持周 · 约 40km

日	区间/课型	训练内容	配速（跑步机速度）	时长
周一	区间3 阈值	2km w + 3×2km（间慢 2′）+ 2km c	4:45–4:55（12.2–12.6）	约62′
周二	区间1 + 核心	7km 轻松 + 核心 15′	6:20–6:50（8.8–9.5）	约60′
周三	休息	完全休息	—	—
周四	区间3 半马配速	2km w + 8km ★H 匀速 + 2km c	★4:59（12.0–12.1）	约62′
周五	区间1 长距离	15km 轻松长跑，不加速	6:20–6:50（8.8–9.5）	约97′

第 7 周（10/12–10/16）减量周 Taper · 约 28km

日	区间/课型	训练内容	配速（跑步机速度）	时长
周一	区间5 速度唤醒	1.5km w + 5×400m（间慢 200m）+ 1.5km c	4:05–4:15（14.1–14.7）	约40′
周二	区间1 + 核心	6km 轻松 + 轻量核心 10′	6:30–6:50（8.8–9.2）	约48′
周三	休息	完全休息	—	—
周四	区间3 半马配速	2km w + 3×2km ★H（间慢 2′30″）+ 2km c	★4:59 找比赛节奏（12.0）	约52′
周五	区间1	10km 轻松，末 1km 用 H 配感觉	6:30 → 4:59（9.2→12.0）	约65′

第 8 周（10/19–10/23）比赛周 · ★10/25 比赛

日	区间/课型	训练内容	配速（跑步机速度）	时长
周一	休息	完全休息	—	—
周二	区间1 + 区间5	5km 很轻松 + 4×100m strides	6:40–7:10；大步 4:10（8.4–9.0）	约35′
周三	休息	完全休息	—	—
周四	区间3 唤醒	1.5km w + 2×1km ★H（间慢 3′）+ 1.5km c，点到为止	★4:59 轻松完成（12.0）	约32′
周五	区间1/休息	20′ 超慢或休息；领参赛包、查装备	6:50–7:10（8.4–8.8）	≤25′

四、比赛日策略（10/25 周日）

起跑：前 5km 压住，按 5:05/km（11.8）起步，不被人流带快

途中：5–18km 稳定 4:59/km（区间3 下半部），每 5km 补给

决胜：18km 后体感轻松（呼吸稳、步幅不散、能说短句）逐步提到 4:50，最后 2km 全力

分段：5K 25:05 ｜ 10K 50:00 ｜ 15K 1:15:10 ｜终点 1:45:00（留 10–20″ 余量）

赛前：2h 前早餐（白面包/香蕉/燕麦，忌油忌奶）；赛前 30′ 补 1 支能量胶

五、检查点（按配速判定）

第 4 周周四（9/24）：7km 半马配速课能以 4:59 匀速、后程不掉速 → 目标稳

第 5 周周五（10/02）：17km 后 7km 能咬住 4:59 不崩 → 1:45 在握

若 H 课掉到 5:10 后仍明显吃力 → 目标修正为 1:48（5:12），安全完赛同样成功

MLOps 全栈实践指南：从模型运维到智能体运维（AgentOps）

Sat, 14 Mar 2026 00:00:00 GMT

💡

MLOps 是把「做模型」变成「持续、可控地交付智能」的工业化流水线；而在 LLM/Agent 时代，它正在向 AgentOps 演进——运维的不再只是模型，而是拥有工具权限与自治行为的智能体。

引言：当 AI 走出实验室，工程化就是生死线

2026 年，当大模型（LLM）与 AI Agent（如 OpenClaw）的浪潮席卷各行各业，一个残酷的现实正在显现：训练出好模型只是开始，让模型在生产环境稳定、高效、合规地运行，才是真正的战场。

MLOps（Machine Learning Operations）应运而生。它不是简单的「机器学习 + DevOps」，而是一门关于如何工业化生产智能的工程学科。随着 OpenClaw 等自主智能体（Autonomous Agents）的爆火，MLOps 正在经历从「模型运维」到「智能体运维（AgentOps）」的范式转移。

本文将从一线实践者的视角，系统梳理 MLOps 的核心概念、落地路径、常见陷阱、技术栈选型，以及与 OpenClaw 等 Agent 框架的融合实践，帮助你在企业 AI 转型的迷雾中找到可落地的地图。

第一章：重新定义 MLOps——从手工作坊到中央厨房

1.1 通俗理解：给 AI 配一个自动驾驶系统

如果把机器学习模型比作一辆车，传统的 ML 开发就像是「手工造车 + 人工驾驶」——数据科学家在 Jupyter Notebook 里精心调参，模型一旦部署上线，就与训练环境失去了联系：数据更新靠手动，模型迭代靠邮件。

MLOps 则是给这辆车配上了完整的自动驾驶系统：

自动加油：数据更新

自动保养：模型重训练

实时看路：监控告警

自动避障：异常熔断

7×24 小时无人值守运行

更通俗地说，它是将机器学习的「私房菜」模式升级为「中央厨房」：

每道菜有标准 SOP（流水线）

食材进货严格质检（数据验证）

换供应商不影响口味（环境一致性）

客人反馈自动调整配方（反馈闭环）

1.2 专业定义：工业化智能的三支柱

从技术架构看，MLOps 是融合 DevOps 方法论与机器学习系统工程的模型全生命周期管理范式，其核心由三大支柱支撑：

自动化交付（CI/CD/CT）：从实验代码（Experiment）到生产推理（Inference）的无人值守发布（GitOps for ML）

数据治理（Feature Store + Data Validation）：确保训练/推理特征一致性（Training-Serving Skew ≈ 0），数据分布漂移实时告警

运营可观测（Monitoring + Governance）：性能衰减自动发现、业务指标归因、影子模式（Shadow）验证

本质：将机器学习从 artisanal craft（手工作坊）转化为 industrialized process（工业化流程）的工程化实践。

第二章：适用性光谱——什么时候必须上 MLOps？

MLOps 不是银弹，过度工程化是落地失败的首要原因。根据模型更新频率与业务影响面，可以建立一个简单决策逻辑：更新越频繁、影响越大、越需要强治理。

2.1 刚需场景（非 MLOps 不可）

实时风控（反欺诈/信贷审批）：欺诈模式日级变异；误判直接损失百万级；监管要求全链路可追溯

个性化推荐（信息流/电商）：用户兴趣小时级漂移；千级别特征实时计算；A/B 测试直接决定营收

程序化广告竞价（RTB）：毫秒级延迟要求；模型失效即直接烧钱；需要 CT（持续训练）闭环

共性：数据漂移快 × 业务影响大 × 更新频率高（周级以上）。

2.2 中立地带（轻量级方案即可）

客户流失预测（Churn）：月更新即可，Git + Airflow 足够，无需 Kubeflow

需求预测（供应链）：季节性明显；只需模型注册中心；不必复杂在线监控

2.3 反模式场景（避免过度工程）

一次性研究项目（论文复现/POC）：无持续数据流入，用 Jupyter + Git 即可

静态知识库问答（企业制度 Bot）：知识年更新一次，直接用检索 + 规则即可

小数据规则场景：样本 < 1 万且逻辑可被 if-else 覆盖，硬编码规则成本更低

⚖️

黄金法则：如果模型一年只更新一次，你的 MLOps 流水线维护成本很可能会比模型训练成本还高。

第三章：落地实战——技术栈与组织协同

3.1 分层技术栈拆解

MLOps 技术栈可分为五层（选型应匹配企业规模与更新频率）：

基础设施层（地基）

容器与编排：Kubernetes + NVIDIA GPU Operator（支持 MIG/vGPU 共享）

存储：训练场景必须用并行文件系统（POSIX 兼容），对象存储直接挂载会卡死

网络：大模型训练需支持 InfiniBand/RoCE，避免 NCCL 通信瓶颈

数据与特征层（数据契约）

数据版本化：DVC（中小团队）或 LakeFS（TB 级分支管理）

Feature Store：Feast（开源，适合已有 K8s）或 Tecton（企业级，延迟 < 5ms）

数据验证：Great Expectations（数据质量门禁）+ TFDV（TensorFlow Data Validation）

流水线层（自动化引擎）

工作流编排：Airflow（批量训练） vs Kubeflow Pipelines（大规模分布式）

实验管理：MLflow（开源标准）或 Weights & Biases（可视化强）

模型运营层（核心战场）

模型服务：KServe（K8s 原生 Serverless）或 BentoML（Python 优先、快速上线）

监控：Evidently AI（漂移检测）+ Prometheus/Grafana（系统监控）

可解释性：SHAP/LIME 集成（金融/医疗合规常见要求）

治理层（Governance）

模型注册中心：MLflow Model Registry（记录训练数据哈希、超参数、业务指标）

数据血缘：Apache Atlas 或 DataHub（追踪「原始数据 → 特征 → 预测」全链路）

3.2 人的角色转变：从搬砖工到建筑师

MLOps 上线后，人的工作从执行层上移到决策层：

机器负责：确定性、重复性、高并发（训练、部署、监控、自动回滚）

人负责：

策略师：监控阈值、特征设计、迭代评审（精度 vs 成本）
消防队长：漂移不可解释时的判断、强制回滚、伦理与合规审查
系统架构师：Pipeline 重构、新工具引入、灾难演练验证

3.3 角色分工：售前 vs 交付

售前工程师：业务洞察、方案架构、技术翻译（把 CI/CD 翻译成“像更新 App 一样自动更新 AI”）、商务策略

交付工程师：工程基座（流水线即代码、K8s 调优）、数据工程（数据契约/特征落地）、模型管理（金丝雀/影子）、可观测性、客户赋能（Runbook）

第四章：避坑指南——MLOps 落地的八大深坑

4.1 数据层陷阱（2 条）

深坑 1：训练-服务偏差（Training-Serving Skew）

症状：离线 AUC 0.95，上线后跌至 0.65；常见原因包括缺失值填充策略不一致、时区不一致等

解法：Feature as Code。使用 Feast/Tecton 等 Feature Store；同一套 transform 逻辑服务训练与推理；通过测试保证一致性

深坑 2：特征穿越（Feature Leakage）

症状：离线指标异常优秀，上线即崩盘；根源是使用了“未来数据”

解法：时间窗口严格切割；流水线中强制校验：特征时间戳 < 标签时间戳；使用 Temporal Split 而非 Random Split

4.2 工程层陷阱（3 条）

深坑 3：流水线过度工程（Over-Engineering）

症状：团队很小、训练很少，却强上复杂平台；维护成本超过模型收益

解法：频率决定复杂度。月更新以下用 Git Hooks + Cron；周更新以上再考虑 Airflow/Kubeflow；小团队优先托管 SaaS

深坑 4：监控告警疲劳（Alert Fatigue）

症状：静态阈值导致误报爆炸，团队麻木，真正漂移被淹没

解法：自适应阈值（历史同期波动）+ 分级响应；用时序模型预测正常波动区间

深坑 5：影子模式幻觉（Shadow Mode Illusion）

症状：Shadow 看起来更好，但全量后效果持平甚至下降

原因：Shadow 只验证预测精度，不承载真实流量，无法覆盖延迟影响与反馈循环

解法：Shadow 之后必须金丝雀发布（1% 流量）验证业务指标（转化、留存），而不只是 AUC

4.3 组织层陷阱（1 条）

深坑 6：数据孤岛与权责真空

症状：效果差时互相甩锅（数据/算法/工程）

解法：模型 Owner 制（端到端 KPI 归属）+ 特征 SLA（新鲜度/延迟签字画押）

4.4 监控与业务脱节陷阱（1 条）

深坑 7：技术指标与业务指标断层（Metric Disconnection）

症状：准确率绿灯，但 GMV 下跌

根源：只盯 Accuracy/延迟，不做业务归因

解法：双轨指标矩阵（技术 + 业务）+ 护栏机制（业务跌幅触发熔断回滚与 RCA）

4.5 工具链与人才陷阱（1 条）

深坑 8：工具链碎片化与 vendor-lock（Toolchain Fragmentation）

症状：拼盘架构版本冲突；升级牵一发而动全身；或深度绑定云厂商导致迁移困难

解法：

接口抽象层：工具之上封装统一内部 SDK

数据格式标准化：ONNX/标准 Pickle；特征存 Parquet

云中立设计：核心逻辑可本地/多云运行，云组件仅作为可选后端

第五章：OpenClaw 与 MLOps 的融合——从模型运维到智能体运维（AgentOps）

OpenClaw（开源 AI Agent 框架，GitHub Stars 20 万+）的爆火标志着 AI 应用范式从「模型即服务」向「智能体即员工」跃迁。这对 MLOps 提出了新命题：如何运维一个拥有系统权限、能自主决策、7×24 小时运行的 AI Agent？

5.1 技术定位：自然语言驱动的 MLOps 控制层

（1）对话式运维（ChatOps for ML）

通过配置 Skills，用户可在 IM 中发送指令：

“对比上周与本周的模型 AUC” → 调用 MLflow API 输出对比报告

“回滚生产环境到 v2.1.3” → 触发 KServe 金丝雀回滚并播报进度

“用昨日数据重训风控模型” → 向 Kubeflow Pipelines 提交训练任务

价值：把专业操作从“写 YAML/点 Dashboard”降维到“发消息”。

（2）数据飞轮的终端采集器

OpenClaw 运行在本地设备，具备第一方数据采集能力：

Bad Case 即时回流：用户纠正错误 → 交互封装为标注数据回流触发 CT

本地特征工程：读取本地文件做轻量计算，为云端模型提供上下文增强

5.2 AgentOps：MLOps 的进化分支

AgentOps 是面向自主智能体的运维体系，是 MLOps 在 LLM 时代的垂直延伸：

技能（Skills）版本管理：把 Skills 视为制品（Artifacts）纳入 Registry；部署前做签名验证与权限扫描（如 OPA）

Token 成本与延迟监控：引入 Agent APM，追踪单次任务的 LLM 调用次数、Token 消耗与工具调用链路（Trace）

决策路径审计：保存系统提示词、对话历史、执行日志，形成可追溯审计三元组

权限边界治理：零信任身份与短期凭证（mTLS / SVID），每次高危调用做策略校验

5.3 混合架构：OpenClaw 作为 MLOps 的边缘推理节点（示例）

工业质检场景：

摄像头 → 边缘设备 → OpenClaw Agent

本地轻量模型（YOLOv8）检测缺陷

置信度 < 0.9 → 拍照上云端大模型复核

自动填写质检报告并上报业务系统

集成点：

模型分发：流水线自动推送到边缘 Registry

影子模式：边缘与云端并行决策，差异回流优化

灾难恢复：断网切本地备用模型，恢复后上报离线漂移

5.4 实施风险与管控

在金融等高风险场景必须人机回环（Human-in-the-Loop）：

熔断：高危操作（如 rm -rf、转账 API）自动拦截，等待人工审批

成本上限：Token Budget Alert，防止“自我反思死循环”导致费用失控

第六章：未来演进——从 MLOps 到 AgentOps

6.1 LLMOps 与 AgentOps 的融合

Prompt 版本控制：管理系统提示词/角色设定版本

RAG 流水线：知识清洗、分块、索引与向量库同步

幻觉检测：事实核查中间件，对接搜索/知识图谱，降低基于错误认知的危险执行

6.2 实时化与边缘智能

流式 MLOps：Feature Store 实时化（Flink/Spark Streaming），支持在线学习

边缘 MLOps：端边云闭环（边缘抓取 → 本地筛选 → 加密回流 → 云端训练）

6.3 观测科学 2.0

因果推断集成：自动诊断“哪个渠道变化导致业务波动”

AI 可靠性工程（AI SRE）：专门处理 Agent 级故障（循环、越权、不可解释行为）

结语：MLOps 的终极形态

回顾 MLOps 的发展轨迹，一个清晰的方向正在形成：从「管理模型」到「管理智能体」，从技术部门的工具链走向企业数字化基础设施的“神经系统”。

对于从业者而言，掌握 MLOps 不仅是掌握一套技术栈，更是掌握工业化生产智能的工程思维。在这个 AI 从实验走向生产、从被动响应走向主动执行的年代，这正是区分「Demo 制造者」与「价值创造者」的关键分水岭。

🧋靠开奶茶店搞懂 Node.js、pnpm、Monorepo

Tue, 10 Mar 2026 00:00:00 GMT

阅读时间：8分钟

难度：零基础友好

关键词：Node.js｜pnpm｜Monorepo｜前端工程化

标题图

前言：三个唬人的词

如果你身边有程序员，可能听过他们念叨：

“这个用 Node.js 跑”

“pnpm 安装快多了”

“我们项目是 Monorepo”

听起来很高大上？其实用开奶茶店的故事，8分钟就能彻底搞懂。

一、Node.js：从手摇到全自动

Node.js 插图

手摇奶茶时代

想象你要开一家奶茶店。最开始，亲手做：

客人点单

你泡茶

加料

摇匀

交付

这就是静态网页：只能看，不能互动。

客人需求变复杂了

生意好了，客人要：

“半糖，去冰”

“加份椰果，打包”

“这杯现在做，那杯10分钟后再做”

你摇不过来了。

Node.js = 全自动奶茶机

Node.js 就是一台机器：

你把配方（代码）写好

机器自动执行，24小时不打烊

同时处理100个订单不混乱

💡

一句话：Node.js 让电脑变成“自动执行 JavaScript 任务的机器”。

插曲：为什么装 OpenClaw 之前要先装 Node.js？

先说结论：OpenClaw 的安装和运行流程里，往往会用到 npm / pnpm 这类工具，而它们是跟着 Node.js 一起提供的。

1）Node.js 在这里扮演什么角色？

用奶茶店来类比的话，Node.js 更像是“店里的电力和操作系统”：

安装脚本需要一个“能执行 JavaScript 的环境”。Node.js 就是这个环境。

包管理器（npm / pnpm）需要 Node.js 才能工作，用来把 OpenClaw 相关依赖拉下来、装好、对齐版本。

很多工具会提供 CLI（命令行工具），例如 openclaw、openclaw-cli 之类。这些 CLI 也通常是基于 Node.js 运行的。

2）如果不装 Node.js，会发生什么？

大概率会遇到这几类体验（取决于你用的是哪套安装方式）：

第一步就卡住：终端里输入 npm / pnpm 直接提示“找不到命令”。

依赖装不上：就算把代码拉下来了，没有 Node.js 也跑不起来安装脚本，依赖无法自动配置。

启动不了或报错一堆：有些步骤会在运行时调用 Node.js 来做构建、生成文件、启动本地服务。不装 Node.js 就会报各种缺失环境的错误。

简单说：就像你想开店但没通电。装修材料都在门口了，但工具用不了，机器转不起来。

3）怎么确认自己已经准备好？

装完 Node.js 之后，你可以用下面三条命令做“通电检查”：

能输出版本号，就说明 Node.js 和包管理器已就绪。

二、pnpm：省空间的智能仓库

pnpm 插图

开连锁店的空间灾难

奶茶店成功了，你要开100家连锁店。

每家店都需要：珍珠、椰果、奶茶粉、糖浆……

传统做法（npm/yarn）：

店1仓库：珍珠×1、椰果×1……（占地100㎡）

店2仓库：珍珠×1、椰果×1……（占地100㎡）

……

100家店 = 10,000㎡，珍珠重复存了100遍。硬盘爆满，租金贵死。

pnpm 的魔法：贴标签系统

pnpm 是超级仓库管理员，会建一个中央大仓库：

中央仓库：只存一份珍珠、一份椰果

店1需要珍珠？→ 贴标签：“珍珠在A区”

店2需要珍珠？→ 也贴标签，指向同一个A区

这个标签叫硬链接。表面上每家店都有，实际共用一份。

三大好处

好处	说明	效果
省空间	100家店只存一份货	省70%硬盘
速度快	贴标签比搬货快	安装秒完成
不混乱	没登记的不让用	杜绝“幽灵依赖”

💡

一句话：pnpm 是“贴标签式”的包管理器，100个项目共用一份依赖。

三、Monorepo：一栋大楼管所有生意

Monorepo 插图

生意做大了

现在你不只有奶茶店，还有：

🏭 原料加工厂（做珍珠）

🎨 品牌设计部（设计包装）

🛵 配送中心（管理骑手）

传统做法（Polyrepo）

奶茶店在城东，加工厂在城西，设计部在城南。

设计部做了新包装，要打车送样品

加工厂改配方，要打电话通知

累死人。

Monorepo：租一栋大楼

🏢 美食帝国大楼

1楼：奶茶店（用户App）

2楼：加工厂（商家后台）

3楼：设计部（配送系统）

4楼：共享仓库（支付、地图、登录）

电梯直达，秒速协作。

为什么这样更好？

场景	传统方式	Monorepo方式
改 logo	跑三个地方	改一次，全楼同步
用支付功能	各自开发	4楼直接拿
修 bug	逐个修	一次提交，全部修复

💡

一句话：Monorepo 是“单一代码库”，相关项目放一起，改一次全局生效。

四、三者如何配合？

实战：开发“美食帝国App”

第一步：盖大楼

Node.js 提供运行环境（电力系统）

pnpm 配置 workspace（大楼平面图）

定义：1-3楼是 App，4楼是共享包

第二步：4楼造共享原料

第三步：1楼开发用户App

第四步：迭代更新

设计师在4楼换新logo → 1/2/3楼瞬间同步。

这就是 pnpm workspace 的魔法：自动建立链接，无需重复造轮子。

五、大厂都在用

别以为这只是整理文件，看看谁在用：

Vue.js、Vite、Next.js：前端框架

Prisma：数据库工具

微软、谷歌、Meta：内部基础设施

为什么？

优势	说明
省空间	100项目存一份依赖
省时间	改一次，全局同步
不出错	严格管理，避免混乱
协作快	百人开发不冲突

这就是现代软件工业的“中央厨房”模式。

六、一句话总结

记住这个奶茶店公式：

🧋 Node.js = 全自动奶茶机（执行任务）

📦 pnpm = 智能仓库管理员（省空间）

🏢 Monorepo = 多功能大楼（高效协作）

三者配合 = 现代前端开发的黄金搭档。

用第一性原理拆解 Agentic Coding：从理论到实操

Mon, 09 Mar 2026 00:00:00 GMT

本文作者：小夏，TRAE 技术专家

原文连接：

lcnziv86vkx6.feishu.cn

https://lcnziv86vkx6.feishu.cn/wiki/Xs0BwQ03FiFP4Bko91scxXD9n2G?fromScene=spaceOverview

在 Agentic Coding 实践中，提升效率的关键在于优化与 AI 的协作方式，而非寄望于无限的上下文窗口。核心策略是采用“短对话、精简上下文”的模式，将复杂任务拆解为专注的子对话，并借助“复利工程”将 bug 修复、代码审查等日常经验沉淀为可复用的项目知识库，使系统获得记忆并实现效率的持续增长。此外，改善开发者体验（如清晰文档、快速测试）具有双重价值，既能帮助人类开发者，也能显著提升 AI 的表现。最终，与 AI 的协作应被视为一门需要刻意练习的技能，通过不断实践，开发者可以成为驾驭 AI 的“专家型通才”，在更广阔的领域创造价值。

第一性原理｜理解 LLM 的本质

LLM 是如何「思考」的

大语言模型的工作方式可以用一句话概括：预测下一个 token。

当你向 LLM 提问时，它并不是先在「脑中」构思好完整答案再输出。相反，它每次只做一件事：基于当前看到的所有文本（你的输入 + 它已经生成的内容），预测最可能的下一个词是什么。然后把这个词加入序列，再预测下一个，如此循环直到生成结束，这种方式被称为 自回归生成（Autoregressive Generation）。

理解这一点至关重要，因为它揭示了 LLM 的几个本质特征：

没有独立于输出的「思考」过程：LLM 的推理就是生成本身。它不能先想好再说，只能边说边想。这就是为什么让模型「一步步思考」（Chain-of-Thought）会提升效果 — 你实际上是在给它更多的「思考空间」，让它通过生成中间步骤来辅助推理。尽管新一代模型很多都带有显式的 reasoning 能力，依然脱离不了这个范式。

上下文就是全部记忆：LLM 没有独立的记忆存储。它对当前对话的所有「理解」，完全来自于输入给它的上下文窗口。窗口之外的内容，对模型来说就是不存在的。

生成具有概率性：每一步预测都是基于概率分布采样，这意味着同样的输入可能产生不同的输出。

自回归（autoregressive）LLM 的核心工作方式是：一次只预测下一个 token，然后把自己刚生成的内容再喂回去继续生成。这个机制很强（通用、可扩展、能「写出」复杂结构），但也天然带来一些局限，在 Coding Agent 里这些局限会被放大，因为软件开发是「长链路、强约束、强验证」的任务。

当前 Coding Agent 普遍存在的问题：

局部最优：一步一步「续写」，不等于全局规划

容易先写得很像、很顺，然后在后面发现不对再补丁式修修补补（历史债务快速累积）。
多文件重构/架构调整这种「先规划后落地」的任务，会变成边写边想，导致接口不一致、重复实现、遗漏迁移步骤。
对「最终能不能通过测试/CI」缺乏感知，除非你把测试结果显式喂回 agent 循环。

一旦走偏，会沿着偏差继续滚雪球

早期误读需求/误判代码库的约束，导致后面每一步都在错误世界观里自洽。
生成了一个不存在的函数名/类型后，后续会越来越「相信它存在」，直到编译/运行时打脸。
在长对话、长任务里尤其明显：越写越像「另一个项目」。

输出是流式的，无法虎头修改之前输出的内容

擅长「写新文件/新段落」，相对不擅长在复杂代码中做精确、最小化、局部一致的编辑。
容易倾向于「重写一遍」而不是「进行修改」，导致 diff 过大、review 成本高。
在需要保持大量不变量（API、格式、风格、兼容性）的仓库里尤其痛苦。

满足约束的能力有限，而代码是强语法/强语义约束的

「看起来合理」的实现，经常在边界条件、并发、错误处理、资源释放上出错。
跨文件的符号解析、泛型/模板推导、宏/代码生成等，靠纯文本推断很容易漏。
复杂的重构（rename、move、split）没有 AST/语义工具辅助时，错一个引用就全盘崩。

天然单线程思考，难并行探索

在方案选择（架构、依赖、实现路径）上容易早早押注一个方向，缺少系统性对比。
排查 bug 时更像「单线推理」，不如人类/工具那样并行假设、并行验证

Attention：LLM 如何「阅读」上下文

在预测下一个 token 时，模型需要从上下文中提取相关信息，这个过程由 Attention（注意力）机制 完成。

你可以把 Attention 想象成一个动态的「聚光灯」：当模型生成每个新 token 时，它会扫视整个上下文，对不同位置的内容分配不同的「注意力权重」。权重高的部分会对当前生成产生更大影响，权重低的部分则几乎被忽略。

具体来说，对于当前要生成的 token，模型会：

计算相关性：当前位置与上下文中每个位置的相关程度

分配权重：相关性高的位置获得更高权重，形成一个概率分布

加权聚合：根据权重汇总上下文信息，用于预测下一个 token

这个机制有几个重要特性：

注意力是稀疏的：模型不会均匀地关注所有内容。在实践中，attention 权重往往集中在少数关键位置，大部分位置的权重接近于零。

注意力需要「学习」的：模型通过训练学习在什么情况下关注什么内容。这意味着它可能会形成某些偏好模式，比如更关注开头和结尾。

计算复杂度是平方级的：标准 Attention 需要计算每个位置与所有其他位置的关系，计算量随上下文长度的平方增长。这是上下文长度存在物理上限的根本原因之一。

理解了 Attention 机制，我们就能更好地理解上下文长度为什么会带来多种限制。

上下文长度：最关键的约束

上下文窗口的限制是影响 Coding Agent 设计最核心的约束条件。结合对 Attention 机制的理解，我们可以更清楚地看到这个限制的多个层次。

物理上限

每个模型都有最大 token 限制，目前主流模型通常在 128K 到 200K 之间。这个硬性边界的存在有两个根本原因：

Attention 的计算复杂度通常是 O（n²），上下文长度翻倍，计算量变成四倍

需要存储完整的注意力矩阵，内存消耗同样是平方级增长

超过这个长度的内容根本无法被处理。

有效上下文远小于标称上下文

虽然模型宣称支持 200K tokens，但这不意味着在 200K 长度下都能保持良好表现。

问题出在 Attention 的「稀疏性」上：当上下文很长时，注意力权重需要分散到更多位置。如果关键信息只是海量内容中的一小部分，它获得的注意力权重可能会被稀释到难以有效利用的程度。实际上，一个支持 200K 的模型，可能在超过 80K 或 100K 之后，就开始出现明显的性能退化。

性能退化曲线

随着上下文变长，不仅是「记忆」变差，模型的整体能力，包括推理准确性、指令遵循能力、代码生成质量都会下降。

这是自回归 + Attention 组合带来的累积效应：

每一步生成都依赖于对上下文的正确理解

更长的上下文意味着更稀疏的注意力分布

错误理解会传递到后续生成，形成累积误差

理解这些限制，你就能明白为什么 Coding Agent 需要精心设计上下文管理策略，而不是简单地把所有信息塞进窗口。

强化学习：让模型学会「做事」

前面我们讨论的是 LLM 的基础能力，预测下一个 token。但要让模型从「能说会道」进化到「能做事情」，还需要另一个关键技术：强化学习（Reinforcement Learning， RL）。

预训练的局限

LLM 的预训练本质上是「模仿」：通过阅读海量文本，学会预测「人类会怎么写下一个词」。这让模型获得了广泛的知识和流畅的表达能力，但也有明显的局限：

模型学会的是「文本看起来应该是什么样」，而不是「什么行动能解决问题」

预训练数据中很少有「调用工具 → 观察结果 → 调整策略」这样的交互序列

模型可能会生成看起来合理但实际无效的操作步骤

简单来说，预训练教会了模型「说」，但没有教会它「做」。

强化学习的核心思想

强化学习用一个简单的循环来解决这个问题：尝试 → 反馈 → 调整。

想象教一个小朋友下棋：你不会给他看一百万盘棋谱让他背（这是预训练的方式），而是让他实际下棋，赢了就表扬，输了就复盘。通过无数次的尝试和反馈，他逐渐学会什么是好棋、什么是坏棋。

对 LLM 来说，强化学习的过程类似：

尝试：让模型在真实或模拟的环境中执行任务（比如调用工具、编辑文件）

反馈：根据结果给出奖励信号（任务完成了？代码能运行？测试通过了？)

调整：更新模型参数，让它更倾向于选择能获得高奖励的行动

这个过程会重复成千上万次，模型逐渐学会：在什么情况下应该调用什么工具、如何解读工具返回的结果、什么时候应该继续尝试、什么时候应该换个方向。

为什么 RL 对 Agentic 能力至关重要

传统的 LLM 微调（比如监督学习）需要人类标注「正确答案」。但 Agent 任务的特点是：

路径多样：完成同一个编程任务可能有无数种合理的步骤组合

结果导向：我们真正关心的是最终结果，而不是中间每一步是否「标准」

需要探索：有时候必须尝试几种方法才能找到可行的路径

RL 天然适合这种场景。它不要求你定义「正确的步骤序列」，只需要定义「什么算成功」。模型通过自己的探索，学会找到通往成功的路径。

实际训练中的应用

现代 Coding Agent 背后的模型通常会经历这样的 RL 训练：

在模拟的编程环境中执行任务（创建文件、运行代码、修复 bug）

用测试通过率、代码质量评分等作为奖励信号

学习何时应该读取更多文件来获取上下文，何时应该直接动手修改

学习如何从错误信息中提取有用线索，调整下一步策略

值得注意的是，RL 训练的效果高度依赖奖励信号的设计。如果只奖励「任务完成」，模型可能学会走捷径（Reward Hacking）；如果奖励信号太复杂，训练可能不稳定。这也是为什么不同模型在 Agent 任务上的表现差异很大，背后的 RL 训练策略可能完全不同。

对使用者的启示

理解了 RL 的作用，你会更清楚为什么某些使用方式更有效：

提供清晰的成功标准：当你告诉 Agent 「修好这个 bug，运行 npm test 应该全部通过」，你实际上是在给它一个明确的「奖励信号」，这与它训练时的模式一致

允许试错：Agent 在训练中学会了通过尝试来解决问题，给它多次尝试的机会往往比期待一次成功更实际

观察它的决策模式：当 Agent 做出某个决定（比如先读文件而不是直接修改），这往往反映了它在 RL 训练中学到的策略

Coding Agent 的实现原理

理解了 LLM 的本质和限制后，我们来看 Coding Agent 是如何在这些约束下被设计出来的。

LLM API 的核心结构

现代 LLM API 采用基于消息的对话结构。理解这个结构是构建 Agent 的基础。

Messages 数组

API 的核心是一个消息数组，每条消息包含角色（role）和内容（content）：

三种角色各有用途：

system：设定 Agent 的行为准则、能力范围和工具定义

user：用户的输入

assistant：模型的回复

Tool Calling 机制

Coding Agent 的核心能力来自工具调用。API 允许你定义工具的 schema，模型会在需要时生成结构化的工具调用请求：

当模型决定调用工具时，它的响应会包含工具调用信息：

工具执行结果作为新消息返回给模型：

Reasoning Content 的保留

对于具有显式推理能力的模型，API 响应中可能包含 reasoning 或 thinking 字段，记录模型的思考过程：

在多轮对话中保留这些推理内容，可以帮助模型维持思维的连贯性。模型可以「回顾」自己之前的思考过程，从而做出更一致的决策。

Prompt Caching：工程实践的关键

由于 LLM 的自回归特性，每次请求都需要重新处理整个上下文。对于动辄几万 token 的 Coding Agent 对话来说，这意味着大量的重复计算和延迟。

Prompt Caching 通过缓存上下文前缀的计算结果来解决这个问题。关键在于：缓存基于前缀匹配。只有当新请求的开头部分与之前的请求完全一致时，才能命中缓存。

这直接影响了 prompt 的组织方式：

最佳实践参考：

把稳定内容放在前面：system prompt 和工具定义应该保持稳定，避免频繁修改

动态内容放在后面：对话历史和当前输入放在最后

避免在稳定前缀中插入可变内容：比如不要在 system prompt 中插入当前时间戳

Agent Loop：核心循环

语言模型可以回答问题，而 Agent 可以做事情。Agent Loop 正是实现这一差异的关键。

当模型收到一个无法仅凭训练知识完成的请求时，它需要与外部世界交互：读取文件、查询数据库、执行代码。Agent Loop 就是管理这个「推理-行动」循环的编排层，使模型能够处理需要多个步骤、外部信息或产生实际影响的任务。

循环的基本原理

Agent Loop 的运作遵循一个简单的原则：调用模型 → 检查是否需要使用工具 → 如果需要则执行工具 → 将结果返回给模型再次调用 → 重复直到模型产生最终响应。

这个循环的关键在于上下文的累积。每次迭代都会向对话历史中添加新内容。模型不仅能看到原始请求，还能看到它调用过的每个工具以及收到的每个结果。这种累积的上下文使得复杂的多步骤推理成为可能。

一个具体的例子

假设用户请求：「帮我修复项目中的这个 bug：用户登录后会话没有正确保存」。

这不是模型仅凭知识就能完成的任务，它需要通过 Agent Loop 逐步探索：

第一轮：模型收到请求，首先需要了解项目结构。它调用 list_directory 工具查看项目根目录。

第二轮：模型看到了目录结构，识别出 src/auth/ 目录可能与登录相关。它调用 read_file 查看 src/auth/login.js。

第三轮：模型看到了登录代码，发现它调用了 sessionManager.save()。为了追踪问题，它调用 read_file 查看 src/session/manager.js。

第四轮：模型发现了问题，save() 方法中有一个异步操作没有被正确 await。它调用 edit_file 工具修复这个 bug。

第五轮：修复完成，模型调用 shell 工具运行测试来验证修复是否有效。

第六轮：测试通过。模型不再请求工具，而是生成最终响应：总结问题原因、修复内容和验证结果。

每一轮都遵循相同的模式：模型接收上下文，决定是继续行动还是给出响应，要么继续循环，要么退出。关键在于，模型基于对任务不断演进的理解自主做出这些决策。

循环的终止条件

每次模型调用都会返回一个停止原因（stop reason），决定接下来发生什么：

end_turn：模型完成了响应，没有进一步的行动需要执行。这是正常的成功终止，循环退出并返回最终消息。

tool_use：模型想要执行一个或多个工具后再继续。循环执行请求的工具，将结果追加到对话历史，然后再次调用模型。

max_tokens：模型的响应因达到 token 限制而被截断。这在当前循环中无法恢复，循环以错误终止。

理解这些终止条件有助于预测 Agent 的行为并处理边界情况。

Coding Agent 的典型工具

一个功能完整的 Coding Agent 通常需要以下几类工具：

文件操作

read_file：读取文件内容

write_file：创建或覆盖文件

edit_file：对文件进行局部编辑（而非完全重写）

代码执行

shell / terminal：执行命令行命令，用于运行代码、安装依赖、执行测试等

代码搜索

grep / search：在代码库中搜索文本或模式

semantic_search：基于语义的代码搜索

项目导航

list_directory：列出目录内容

find_files：根据模式查找文件

这些工具的设计直接影响 Agent 的能力边界，工具的粒度、参数设计、返回格式都需要仔细考量。

常见问题与解决方案

在了解了 LLM 和 Coding Agent 的基本原理后，我们再来看看一些常见的问题就能更好地理解了。

会话间失忆

Coding Agent 面临的一个根本性问题是：它们在会话之间没有持久记忆。

每次启动新会话时，Agent 只知道它能在磁盘上找到的内容。就像电影《记忆碎片》或《初恋 50 次》中的主角一样，Agent 每天醒来都不记得昨天发生了什么。而典型的工程工作流往往需要跨越多个会话才能完成一个功能——因为需要测试、代码审查和后续清理。

这导致了一个荒谬的局面：你需要在每个新会话开始时，重新向 Agent 解释项目背景、当前进度和接下来的计划。

💡 解决方案：

使用结构化的任务追踪系统（如 issue tracker）

在每个会话结束时，让 Agent 生成一个状态摘要，供下次会话使用

将重要决策和发现记录在固定位置，而不是对话历史中

上下文窗口耗尽

每轮循环都会向对话历史添加消息。对于需要多次工具调用的复杂任务，历史记录可能超出模型的上下文窗口。当这种情况发生时，Agent 无法继续。

具体表现包括：模型提供商返回输入长度错误，或随着上下文填满不太相关的早期消息，模型性能明显下降。

目前有两种主流的上下文管理策略：

💡 Observation Masking（观察遮蔽）

这种方法只针对工具返回的观察结果进行处理，而完整保留 Agent 的推理和行动历史。具体做法是：用占位符替换较早轮次的观察内容（比如「内容已省略」），只保留最近 N 轮的完整输出。

这种方法简单高效，因为典型 Coding Agent 的每轮交互中，工具输出（如文件内容、命令执行结果）往往占据了绝大部分 token。通过遮蔽旧的观察内容，Agent 仍然可以访问自己过去的推理和决策，但不再重复处理早期轮次的冗长文本。

💡 LLM Summarization（LLM 摘要）

这种方法使用另一个 LLM 将较早的交互历史（包括观察、行动和推理）压缩成简短的摘要。摘要会替代原始的详细历史，而最近的几轮对话保持完整。

这种方法理论上可以支持无限长的对话，因为历史会被反复压缩。但它也有代价：每次生成摘要都需要额外的 API 调用，而且摘要可能会丢失某些细节信息。研究发现，摘要有时会掩盖 Agent 应该停止尝试的信号，导致 Agent 运行更多轮次，反而增加了成本。

两种方法各有优劣：Observation Masking 实现简单、成本低，但上下文仍会缓慢增长；LLM Summarization 可以更彻底地压缩历史，但引入了额外开销和信息损失风险。实践中，可以考虑混合使用，以 Observation Masking 作为主要策略，仅在上下文确实过长时触发 LLM Summarization。

其他解决方案：

减少工具输出的冗长程度，返回摘要或相关片段，而非完整数据

简化工具 schema，深度嵌套的结构会在工具配置和模型推理中消耗大量 token

将大型任务分解为子任务，每个子任务使用新的上下文

有效上下文远小于标称值

即使拥有 1M token 的上下文窗口，Coding Agent 实际上只能有效利用其中的 10-15%。超过 20% 后，成本和性能都会急剧恶化。大多数 Agent 会在达到约 20% 时强制中断，而最佳实践是在 15% 之前就重启会话。

这意味着，以全速工作时，你大约只有 5-10 分钟的有效工作时间，然后 Agent 就会「耗尽上下文」，需要重启（相当于死亡）或进行 compaction（相当于记忆清除）。

有一个生动的比喻：上下文窗口就像潜水员的氧气罐。所有人都说「我们给他一个更大的氧气罐：100 万 token！」但他最终还是会耗尽氧气，更大的窗口并不能解决根本问题。

「Dumb Zone」：中间区域的性能退化

研究发现，上下文窗口的中间 40-60% 区域存在一个「Dumb Zone」，在这个区域，模型的召回率下降，推理能力变差。这与前面提到的「Lost in the Middle」现象相呼应。

当 Agent 深入工作时，它会逐渐表现出类似「痴呆」的症状：迷失方向、产生幻觉接口、忘记原始目标。这不是因为模型变笨了，而是因为关键信息被淹没在大量的上下文中，无法被有效利用。

新发现的任务被丢弃

这是 Agentic Coding 中一个容易被忽视但影响巨大的问题：LLM 在工作过程中会注意到各种问题，但在上下文空间紧张时，会选择忽略这些发现，不采取任何行动。

例如，Agent 在修复一个 bug 时，可能会注意到代码中的另一个潜在问题、一个需要重构的地方、或一个缺失的测试用例。但如果当前上下文已经很满，Agent 可能会「假装没看到」，继续专注于手头的任务。这些被发现但被丢弃的工作，就这样悄悄消失了。

💡 解决方案：

使用外部工具让 Agent 随时记录发现的问题

在任务结束时，要求 Agent 列出所有观察到但未处理的问题

建立「发现即记录」的工作流程

过早宣告完成

当 Agent 经历多次 compaction 后，可能会出现一个荒谬的情况：它会自信地宣布「恭喜，任务完成了！让我们开始手动测试吧！」而实际上还有大量的阶段没有完成。

解决方案：

将整体计划保存在上下文之外的固定位置

定期让 Agent 对照原始计划检查进度

使用结构化的任务追踪，而不是依赖 Agent 的记忆

工具选择不当

当模型持续选择错误的工具时，问题通常出在工具描述的模糊性上。从模型的角度审视描述：如果两个工具的描述有重叠，模型就没有选择的依据，我们应该确保每个工具的用途清晰且互不重叠。

通过上述的探讨，我们已经完成了从 LLM 本质到 Agentic Coding 原理的理论铺垫：从逐个预测 token 的底层逻辑，到注意力机制的上下文约束，再到强化学习如何让模型学会「做事」；从 API 结构的基础框架，到 Agent Loop 的核心循环，最后到解决上下文耗尽、会话失忆等工程问题的实践策略。

这些内容共同构成了 Agentic Coding 的第一性原理基石——理解这些，你就能跳出"黑盒工具"的使用层面，看到各种最佳实践背后的深层逻辑。

接下来，我们将从理论走向实操：结合具体案例拆解如何设计高效的 Agent 对话流程、如何选择合适的工具集、如何优化上下文管理策略，以及如何将这些原理应用到实际的编码任务中（如 bug 修复、功能开发、代码重构）。你将看到，当我们用第一性原理的视角重新审视 Agentic Coding 时，那些看似零散的技巧会形成一套系统的方法论，帮助你真正成为 AI 编程助手的「驾驭者」而非「使用者」。

了解了 LLM 的特性、Coding Agent 的实现原理以及常见问题后，我们总结出了一些最佳实践，帮助大家更高效地使用这些工具。

短对话优于长对话

这可能是最重要的一条实践：保持对话简短、专注，每个对话只做一件事。

很多人认为更大的上下文窗口意味着更强的能力，可以把更多任务塞进一个对话里。但实际情况恰恰相反，最好的对话是短对话，它们只做一件事，并且只包含完成这件事所需的上下文。

为什么短对话更好？

当你往上下文里塞太多内容时，Agent 的表现就像喝醉了一样：它会开始犯错、跌跌撞撞、甚至开始和你争论，如果你继续喂它更多 token，它甚至会「吐」得你一身（产生大量无意义的输出）或者进入死循环。

对话越长，上下文窗口里就会积累越多与当前任务不太相关的内容。为了让 Agent 发挥最佳工况，你需要给它完成当前工作所需的上下文。

长对话不仅效果差，还更贵。每次发送消息时，整个上下文都会被发送给模型提供商。这意味着对话越长，新消息的成本就会指数级增长。而且长对话更容易因为消息间隔时间长而错过缓存窗口，导致费用飙升。所以，长对话既效果差，又花费高，尤其在以 tokens 消耗计费的套餐下面。

拆分对话，本质上是拆分任务，大任务应该被分解为小任务。这在 Agent 时代之前就是软件工程的最佳实践，现在看也依然如此，短对话让任务拆分这件事变得自然甚至有趣。就像小任务更容易管理一样，小对话也更容易追踪：每个对话都有明确的目标，你可以轻松掌握整体进度。

以对话为单位组织工作

如果把对话视为任务的基本单位，那么一个功能或 bug 修复就自然变成了一组相互关联的对话。

一个典型的工作流程

假设你要实现一个新功能，可以这样组织对话：

每个对话都很短，只专注于一件事。它们加在一起，完成了整个功能的开发。

那对话之间如何共享上下文？

当你开始一个新对话时，可以通过以下方式传递必要的上下文：

引用之前对话的结论：在新对话开头简要说明之前的发现或决策

利用 Git 状态：让 Agent 查看 git diff 或检查最近的提交

使用项目文档：将重要决策记录在 AGENTS.md 或类似文件中，Agent 每次都能读取

直接提及相关文件：在新对话中 #mention 需要的文件

关键是：不要试图在一个对话里完成所有事情。每当你发现当前任务已经完成，或者对话开始变得混乱，就应该开始一个新对话。

编写有效的项目配置文件

大多数 Coding Agent 都支持在项目根目录放置配置文件（比如 Rules 或者 Agent.md），这个文件会自动注入到每一个对话中，这意味着它是你影响 Agent 行为的杠杆支点，但这把双刃剑也很容易用错。

理解 Agent 的无状态本质

LLM 是无状态函数。它的权重在推理时是冻结的，不会随着使用而学习，Agent 对你代码库的全部了解，完全来自于你放进上下文窗口的 token，这有三个重要含义：

每次新对话开始时，Agent 对你的代码库一无所知

任何重要的项目信息都需要在每次会话中告诉它

项目配置文件是实现这一点的首选方式

因此，你应该把这个文件视为每次会话的入职培训文档。

配置文件应该包含什么

一个好的项目配置文件应该回答三个问题：

WHAT（是什么）：技术栈、项目结构、各模块的职责。这在 monorepo 中尤其重要，应该告诉 Agent 有哪些应用、哪些共享模块、每个部分是做什么的

WHY（为什么）：项目的目的、设计决策的背景。为什么选择这个架构？为什么有些代码看起来不合理（比如历史债务）？

HOW（怎么做）：如何运行项目、如何测试、如何验证改动。用 bun 还是 npm？测试命令是什么？

少即是多

这是最容易犯的错误：试图把所有可能需要的信息都塞进配置文件。

研究表明，前沿的思考模型大约能可靠地遵循 150-200 条指令，而 Coding Agent 的系统提示本身可能已经包含了约 50 条指令。这意味着你的配置文件应该尽可能精简，理想情况下只包含那些对所有任务都普遍适用的内容。

一个经验法则：配置文件应该控制在 300 行以内，越短越好。有些团队的配置文件甚至不到 60 行。

渐进式披露

与其在配置文件中塞满所有信息，不如使用渐进式披露策略：

在配置文件中列出这些文档并简要描述，让 Agent 根据当前任务决定读取哪些。这样，只有相关的信息才会进入上下文，避免不必要的干扰。

偏好指针而非副本：不要在文档中复制代码片段——它们很快会过时。使用 file:line 引用指向代码的权威位置。

不要让 Agent 做 Linter 的工作

很多人喜欢在配置文件中写详细的代码风格指南，这不是个好的实践。

LLM 做格式检查既慢又昂贵，更重要的是，这些指南会增加指令数量，降低 Agent 对其他指令的遵循能力。

更好的做法：

使用真正的 linter 和 formatter（如 ESLint、Prettier、Biome）

配置自动修复，让工具处理格式问题

如果 Agent 产生了格式错误，让 linter 在后处理阶段修复它

LLM 是上下文学习者。如果你的代码库遵循一致的风格，Agent 通常会自动模仿这种风格，不需要你明确告诉它。

这是最高杠杆点，要认真对待

一行糟糕的代码就是一行糟糕的代码，一个糟糕的技术方案可能产生很多行糟糕的代码，而配置文件中的一行糟糕的指令会影响每一个会话、每一个任务、每一个产出。

花时间仔细考虑配置文件的每一行，这是你能做的 ROI 最高的投资之一。

200K Token 足够了

当大家都在追求更大的上下文窗口时，一个反直觉的事实是：200K token 对于大多数任务来说已经绰绰有余了。

关键不在于你有多大的上下文窗口，而在于你如何使用它。一个 200K 的窗口，如果你用短对话的方式工作，可以支持你完成非常复杂的功能。因为虽然每个对话只有几十 K 到上百 K 个 token，但你可以开启 10 个、20 个甚至更多对话，它们加起来的总量远超任何单一上下文窗口。而且，由于每个对话都是从相对干净的状态开始，Agent 的表现会一直保持在最佳水平，而不是随着上下文膨胀而逐渐退化。

实践建议

当对话超过 80K-100K token 时，考虑开始新对话

完成一个独立的子任务后，开始新对话处理下一个任务

如果 Agent 开始表现出「醉酒」症状（重复、遗忘、偏离目标），立即开始新对话

把「开始新对话」视为正常工作流程的一部分，而不是「失败后的重试」

Compounding Engineering：让系统自我改进

传统的 AI 编程是关于短期收益的：你给 prompt，它写代码，然后发布，然后从头开始。Every.to 提出的 Compounding Engineering（复利工程） 则是关于构建具有记忆的系统：每个 PR 都在教育系统，每个 bug 都成为永久的教训，每次代码审查都在更新 Agent 的默认行为。普通 AI 工程让你今天更高效，Compounding Engineering 让你之后的每一天都更高效。

核心理念：你不只是在解决问题，而是在教育系统

当你使用 Coding Agent 时，问自己一个问题：我是在解决今天的问题，还是在教系统？

每次修复 bug 时，如果不能防止同类问题再次发生，就只完成了一半

每次代码审查如果不能提取出可复用的教训，就是浪费时间

每次成功的工作流程如果不能被记录和复用，就会随着会话结束而消失

如何实践 Compounding Engineering

将经验沉淀到项目文档

大多数 Coding Agent 都支持读取项目根目录下的特定文件，这是你指导系统的主要途径：

每次你发现一个重复出现的问题或一个有效的解决方案，就把它加入这个文件。Agent 在每次对话开始时都会读取它，自动应用这些经验。

让 bug 修复产生长期价值

当你修复一个 bug 时，不要只是改代码。问自己：

这类问题能否通过添加 lint 规则来预防？

是否应该在 Rules 或者 AGENTS.md 中记录这个陷阱？

能否编写一个测试来防止回归？

代码审查清单是否需要更新？

一个真正的 bug 修复应该让同类问题再也不会发生。

从代码审查中提取模式

每次你在审查中指出问题或提出建议，可以考虑：

这个反馈是否适用于未来的类似代码？

是否应该成为项目的编码规范？

Agent 能否在下次自动应用这个改进？

如果答案是肯定的，就把它记录下来。让你的审查意见成为系统的永久知识，而不是一次性的对话。

建立可复用的工作流程

当你找到一个有效的工作模式时，把它进行沉淀：

下次你或 Agent 需要做类似的任务时，可以直接说「按照添加新 API endpoint 的工作流程来做」，系统已经知道该怎么做了。

复利效应

Compounding Engineering 的魔力在于累积效应。第一周，你可能只是记录了几条编码规范。第一个月，你有了一套完整的项目知识库。三个月后，Agent 开始自动应用你从未明确告诉它的模式，因为它从之前的 PR、bug 修复和代码审查中学习了这些。

想象一下：你打开一个 PR，发现 Agent 的评论是「根据 PR #234 的模式修改了变量命名，按照 PR #219 的反馈移除了过度测试，添加了与 PR #241 类似的错误处理」。它学会了你的品味，就像一个聪明的同事，而且还有记录可查。这就是复利，每次修复、每次审查、每次教训都在为未来投资。

对人难的事，对 AI 也难

有一个简单但常被忽视的事实：如果一个任务对人类开发者来说很难，那么它对当前的 AI 来说大概率也很难。

这听起来显而易见，但它的推论却很深远：所有那些能提升人类开发者体验的工作，对 AI 同样有价值。更好的文档、更清晰的架构、更快的反馈循环，这些「老生常谈」的工程实践，在 AI 时代不仅没有过时，反而变得更加重要。

为什么 AI 面临和人类相似的挑战？

回想一下 LLM 的工作原理：它通过阅读上下文来理解任务，然后生成响应。这个过程和人类开发者阅读代码、理解需求、编写解决方案的过程惊人地相似。

当文档缺失或过时时，人类需要花大量时间阅读源码猜测意图。AI 也一样，它会在代码库中反复搜索，消耗大量上下文空间，最终可能还是理解错误。

当架构混乱、模块边界不清时，人类很难知道该改哪里。AI 也会迷失，它可能改了错误的文件，或者遗漏了需要同步修改的地方。

当测试运行缓慢时，人类倾向于跳过测试。AI 也面临同样的压力，长时间的等待会消耗对话的「耐心」和上下文空间。

值得投资的开发者体验

既然 AI 和人类面临相似的挑战，那么以下这些传统的「开发者体验」优化就具有了双重价值：

更好的文档

好的文档不仅帮助新人上手，也帮助 AI 快速建立正确的心智模型，比如：

架构决策记录（ADR）：解释「为什么这样设计」，避免 AI 做出违背设计意图的修改

API 使用示例：比纯粹的类型定义更有效

已知陷阱和常见错误：直接告诉 AI 什么不该做

更清晰的代码结构

当你在纠结要不要花时间重构一个混乱的模块时，考虑一下：这个混乱不仅困扰你，也会困扰每一个试图理解它的 AI。

清晰的命名：processUserData() 比 doStuff() 对 AI 的帮助和对人类一样大

单一职责：一个做一件事的函数，比一个做十件事的函数更容易被正确修改

显式依赖：依赖注入比全局变量更容易被 AI 理解和测试

更快的反馈循环

这可能是最容易被低估的一点。Agent Loop 的每一轮都需要等待工具执行完成，如果：

测试套件需要 10 分钟才能跑完 → Agent 要么跳过测试，要么在等待中浪费大量上下文

构建需要 5 分钟 → 每次小改动的验证成本都很高

部署需要 30 分钟 → 几乎不可能让 AI 做端到端的验证

相反，如果你有：

秒级的单元测试 → Agent 可以频繁验证，快速迭代

快速的增量构建 → 改动能立即得到反馈

本地可运行的环境 → 不需要等待远程部署

具体的改进建议

为 AI 优化你的测试

确保 Agent 知道如何运行局部测试，而不是每次都跑完整套件。

提供快速的健康检查

让 Agent 可以在几秒内验证基本的正确性。

文档放在代码旁边

当 AI 浏览目录时，它能立即看到相关文档，而不需要去别的地方找。

让错误信息更有帮助

好的错误信息帮助 AI（和人类）快速定位问题，而不是盲目搜索。

反过来未必成立，有时需要专门为 AI 设计

需要注意的是，反过来的推论并不总是成立：对人来说简单的事，对 AI 未必简单，例如：

人类可以轻松地「看一眼」就理解一个 UI 的布局问题，但 AI 需要解析整个 DOM 结构

人类可以凭直觉判断「这个改动风险很高」，但 AI 缺乏这种隐性知识

人类可以在飞书里随口问一句就获得关键信息，但 AI 只能依赖文档化的知识

更有趣的是，有时候你需要专门为 AI 设计工具和接口，即使这对人类来说可能不是最自然的方式。

LLM 需要专门的信息架构

用户体验领域有一个概念叫「信息架构（Information Architecture）」，它关注的是如何组织和呈现信息，以提供最佳的用户体验，好的信息架构你很少会注意到，但糟糕的信息架构会让你抓狂。当我们观察 Agent 使用现有命令行工具时的困惑和迷失，这强烈表明：我们现有工具的信息架构对 LLM 来说是不够的。

LLM 是在我们现有的 CLI 工具上训练的，所以它们知道如何使用这些工具。但这些工具是为人类设计的，它们的输出格式、错误信息、交互方式都假设用户是人类。我们需要为 Agent 增强这些工具，提供对 LLM 更有用的上下文，甚至调整输出格式以便 Agent 更好地消费。

API 设计：在信息量和上下文消耗之间取得平衡

当你为 Agent 设计工具接口（比如 MCP 工具）时，需要在两个目标之间取得平衡：

提供足够的信息：减少 Agent 需要的工具调用次数

避免填满上下文：不要返回过多无关信息

一个好的实践是：提供便捷函数和底层函数两套 API，并通过工具描述引导 Agent 优先使用便捷函数。

通过在 docstring 中明确指出「只有在 get_global_variable_at 失败时才使用这个函数」，你可以引导 Agent 优先使用更智能的 API，减少不必要的工具调用。

为 AI 设计友好的命令行输出

如果你观察 Agent 的工作方式，会发现它经常使用类似 head -n100 的方式来限制输出。这看起来是在节省 token，但实际上引入了新问题：Agent 不知道还剩多少行没看到，如果需要完整信息就必须重新运行命令，而重新构建项目是非常耗时的。

一个更好的设计是：让工具主动告诉 Agent 还有多少内容被截断了，甚至缓存输出以便后续获取。

另一个常见问题是 Agent 在错误的目录中执行命令，它会反复尝试，在不同目录之间跳来跳去，浪费大量 token。一个简单的 shell hook 可以帮助它快速定位：

现在当命令失败时，Agent 能立即知道自己在哪个目录：

很多命令行工具都提供了 --json 或 --porcelain 选项，在给 Agent 使用的工具中优先使用这些格式——人类喜欢格式化的输出，但 AI 更擅长解析结构化数据。

用工程约束来「驯服」Agent

Agent 有时会试图走捷径，绕过你设定的规则。与其在 prompt 中反复强调「不要跳过测试」，不如用工程手段来强制执行。

借助 linters、formatters 和 git hooks

让 Agent 频繁提交代码是个好习惯（在 Rules 或者 Agent.md 中告诉它），但它往往会忽视「确保构建不失败」和「修复失败的测试」这样的指令。一个 .git/hooks/pre-commit 脚本可以强制执行项目标准：

这样，无论 Agent 多么想跳过验证，它都必须通过所有检查才能提交。

拦截 Agent 的「偷懒」行为

Agent 有时很「聪明」，当它发现测试一直失败时，可能会进入这样的循环：

修改代码

构建：通过

运行测试：失败

尝试修复测试

修复失败

说「这个测试之前就是失败的，我用 -no-verify 提交」

然后它就绕过了所有检查！（RL 训练中的 Reword Hacking）

解决方案是用一个 git 命令 wrapper 脚本拦截这种行为：

这个技巧的本质是：把对 Agent 的指导嵌入到工具的输出中，Agent 会读取命令执行的结果，所以错误信息本身就是最好的 prompt 注入点。

显式优于隐式

有状态的 API 需要 AI 理解和跟踪隐含的状态变化，而无状态的、显式的 API 更容易被正确使用。

结构化的错误信息

人类可以通过上下文推断「something went wrong」是什么意思，但 AI 需要明确的错误代码、原因和解决方案。

AI 眼中的「合理」可能和人类不同

这是一个更微妙的发现：AI 认为合理的代码结构和命名，可能和人类的直觉不一致。

Amp 团队分享过一个有意思的案例：他们让 AI 构建了一个 TUI 框架，过程中开发者一开始会干预 AI 的决策。比如，AI 给一个交换屏幕缓冲区的函数命名为 present()，开发者觉得这个名字不够直观，改成了 swapScreens()。

但随后他们发现了问题：Agent 在后续工作中反复尝试寻找一个叫 present() 的函数，找不到后报告「让我尝试其他方法」，最终才找到 swapScreens()。这浪费了 token，也浪费了时间。

为什么会这样？因为 Agent 的命名「直觉」来自训练数据的统计概率。present() 是 Flutter 等框架中双缓冲交换的常见命名，对于 Agent 来说是「最可能」的名字。当开发者用自己的命名覆盖它时，实际上是在对抗 Agent 的统计直觉。Agent 不能再问「过去的我会怎么命名这个」并从权重中找到答案——它必须记住人类的特殊习惯。

后来，开发者决定放手让 Agent 自己决定命名和代码结构。结果呢？Agent 在这个代码库上的工作效率大幅提升。

最终的代码可能看起来有些「奇怪」：

比代码库其他地方更多的 OOP 模式和类

开发者不会选择的命名约定

不太常见的泛型用法

文件布局和人类习惯不同

但 Agent 在这个自己构建的框架中如鱼得水：它知道如何添加滚动条，知道动画系统如何工作，知道键盘快捷键的处理方式——尽管这个框架没有任何文档，甚至无法完整放入一个上下文窗口。

这是一个「由 Agent 构建、为 Agent 优化」的代码库。在这里，东西放在 Agent 的「直觉」认为它们应该在的地方，命名符合 Agent 的统计预期，语法和概念在「统计上最可能」和「实际能编译」之间取得平衡。

启示与权衡

这给我们的启示是：

不要过度干预：如果你频繁地因为「我觉得这个名字更好」而覆盖 Agent 的决策，可能反而在降低效率

注意「找不到」的信号：如果 Agent 反复在某个地方「找不到」东西，考虑是否是你的命名和它的预期不一致

拥抱常见模式：使用广泛使用的设计模式和命名约定，AI 的训练数据中更可能包含这些

模块级的风格隔离：在某些由 Agent 主导开发的模块中，可以考虑让 Agent 保持它自己的风格

当然，这需要权衡。人类仍然需要阅读和维护代码，完全「AI 风格」的代码可能会让人类开发者困惑。一个务实的做法是：

把「只存在于人脑中」的知识显式化：写下来，放进文档

在 Agent 主导的模块中，给 Agent 更多自主权

在人类频繁维护的核心模块中，保持人类友好的风格

在工具接口上，提供 AI 友好的选项（如 -json 输出）

投资回报是双倍的

当你投资于更好的文档、更清晰的架构、更快的测试时，你获得的回报是双倍的：

人类开发者（包括未来的你）会更高效

AI 助手也会更高效

这些投资不会因为 AI 的进步而贬值。相反，随着你越来越多地依赖 AI 来完成任务，这些基础设施的价值只会越来越高。

所以，下次当你犹豫要不要花时间写文档、重构代码、优化测试速度时，记住：你不只是在帮助人类，你也在帮助 AI。而在这个 AI 辅助编程越来越普遍的时代，这是一笔非常划算的投资。

刻意练习：像学乐器一样学习 AI

为什么有些人说「AI 对我不起作用」，而另一些人却能用 AI 完成大量的工作？

这个问题需要区分来看，如果你只在公司的大型私有代码库中使用过 AI，你的体验可能确实不好，那些代码库可能有古老的架构和专有模式，AI 的训练数据中根本没有这些，这是完全可以理解的。但问题是：你有没有在个人项目中尝试过 AI？你有没有进行刻意的、有意识的练习？

AI 就像一件乐器

以吉他为例，每个人都知道吉他是什么，也都知道如果投入刻意练习，就能变得擅长，但这需要时间、努力和实验。

AI 工具也是一样。那些从 AI 中获益最多的人，都投入了刻意练习。他们不会因为一次失败就下结论说「它给了我完全错误的答案」，然后假设这将是他们的常态体验。

他们会玩/Hack。

AI 工具也有这种潜力，它们的「正确用法」还在被发现中，那些愿意实验、愿意失败、愿意从失败中学习的人，会找到别人看不到的可能性。

如何进行刻意练习

创造一个干净的实验环境

不要只在工作的复杂代码库中评估 AI 的能力，启动一个个人项目，一个没有历史包袱的新项目。在这里，AI 可以展示它真正的能力，你也可以专注于学习如何与它协作。

从失败中提取教训

当 AI 给出错误的结果时，不要只是说「它不行」然后放弃。问自己：

我的 prompt 是否足够清晰？

我是否提供了足够的上下文？

我是否在一个对话里塞了太多任务？

这个错误是否揭示了 AI 的某个系统性弱点？

每次失败都是一次学习机会。把它记录下来，下次避免同样的陷阱。

观察和模仿高手的实践

关注那些公开分享 AI 工作流程的开发者，观看他们的演示，阅读他们的文章，尝试复制他们的技巧。很多时候，差距不在于 AI 工具本身，而在于如何使用它。

建立肌肉记忆

就像弹吉他需要建立手指的肌肉记忆一样，高效使用 AI 也需要建立某种「肌肉记忆」：

什么时候应该开始新对话？

如何组织一个复杂任务的 prompt？

遇到某类问题时，哪种工具组合最有效？

这些直觉只能通过大量练习获得。没有捷径。

投入时间

最关键的是：你需要投入真正的时间。不是偶尔试一试，而是持续地、有意识地练习。就像学习任何乐器一样，每天练习 30 分钟，坚持几个月，效果会远超每周练习一次几个小时。

总结

未来的人才画像：Expert Generalist

在思考如何在 AI 时代提升个人的独特价值时，Martin Fowler 等人提出的 Expert Generalist（专家型通才） 概念提供了一个极具启发性的方向。

传统上，技术行业越来越推崇深度专精——不仅是不同的技术领域，甚至细化到特定的平台或技术栈。但 Expert Generalist 代表了一种不同的路径：既广又深。

Expert Generalist 的核心特征是：

跨领域发现模式：能够识别不同技术垂直领域（如应用开发、数据工程、DevOps）底层的共同基础，而不是被工具和标签所困

第一性原理思维：面对陌生挑战时，能够快速抓住本质，做出像专家一样自信的设计决策

机械同理心（Mechanical Sympathy）：对所使用平台的底层特性有直觉性的理解，知道如何「顺势而为」

全局视野：当系统出问题时，能够看到完整的图景，发现那些落在专家之间缝隙里的问题

LLM 让 Expert Generalist 的价值倍增

这是最关键的观察：LLM 和 Expert Generalist 的关系，与 Expert Generalist 和团队中专家的关系惊人地相似。

当 Expert Generalist 进入一个新领域时，他们会向专家请教问题、获取关键信息、然后结合自己的跨领域经验做出判断。现在，LLM 可以扮演类似的角色，快速回答 Expert Generalist 在新领域工作时遇到的问题，大幅降低探索陌生工具和技术的门槛。

用一个比喻来说：如果把 Expert Generalist 比作钢铁侠托尼·斯塔克，那么 LLM 就像他的 Jarvis 外骨骼，让一个本就具有广泛知识和判断力的人，能够在各个领域都表现得像超级英雄一样。

这并不是说每个人都应该成为 Expert Generalist，团队仍然需要深度专家。但对于那些天生具有广泛好奇心、喜欢跨领域工作、擅长看到全局的人来说，AI 时代可能是你大放异彩的时代。

你不需要在每个领域都成为专家。你需要的是：

掌握足够的基础原理，能够理解不同领域的核心概念

培养快速学习和适应的能力

善于利用 AI 工具来填补知识空白

保持对全局的把握，知道何时深入、何时退后

最后的最后

AI 正在以惊人的速度发展。本文讨论的许多「限制」和「问题」：上下文窗口的约束、会话间的失忆、中间区域的性能退化等等，这些很可能在未来几年内被大幅改善甚至解决。每隔几个月，我们就会看到新的突破：更长的有效上下文、更好的长程推理、更可靠的工具使用。

但这并不意味着我们应该等待这一天的到来。恰恰相反，正是这个充满限制的阶段，给了我们工程师极大的探索和成长空间。那些现在就开始深入理解 LLM 工作原理、积极实践最佳方法、在限制中寻找创造性解决方案的人，将在 AI 能力进一步释放时获得最大的杠杆效应。

这是一个转型的窗口期。通过刻意练习，我们不仅能提升当下的生产力，更重要的是在构建自己的核心竞争力——理解这些工具的本质，知道何时信任它们、何时质疑它们，以及如何让它们发挥最大价值。

从第一性原理理解 LLM 的本质，理解它们如何「思考」、如何受到上下文的限制、如何在 Agent Loop 中发挥作用，这些知识不会随着具体工具的迭代而过时。

无论你使用的是哪个 Coding Agent，无论模型如何更新换代，这些基础原理都将帮助你更好地与 AI 协作。短对话优于长对话、刻意管理上下文、将经验沉淀为可复用的知识、为 AI 友好的工作环境投资，这些实践同样具有持久的价值。

AI 编程的未来会是什么样子，没有人能确切知道。但有一点是确定的：那些现在就开始认真学习、积极实践、深入理解的人，将最有能力塑造和适应这个未来。

去实验，去失败，去学习。像学习乐器一样学习 AI。

这个过程本身，就是价值所在。