# 前Meta/Microsoft主任工程师kunchenguid的Agentic工程工作流

- 来源：meng shao (@shao__meng)
- 发布时间：2026-06-22 08:35
- AIHOT 分数：67
- AIHOT 链接：https://aihot.virxact.com/items/cmqohj2u8013jslx6nfiz7tyn
- 原文链接：https://x.com/shao__meng/status/2068855273088074173

## AI 摘要

kunchenguid发布45分钟视频，讲解每天交付40-50个生产级PR的工作流。四层：1）终端中心（WezTerm+tmux+Neovim）；2）船员入职：全局memory精简27行，项目级memory由agent自写；3）协作：语音输入OpenSuperWhisper，AXI标准（MCP比CLI多耗3倍token+2倍延迟），Lavish交互式HTML工件；4）验证：no-mistakes流水线在隔离worktree中对抗式review+E2E测试。并行用treehouse管理worktree，First Mate元agent调度。

## 正文

前 Meta/Microsoft/Atlassian 主任工程师的 Agentic 工程工作流

用这套工作流 @kunchenguid 每天 ship 40-50 个经测试的生产级 PR，他这么形容它：「你是船长，agent 是你的船员，分四层递进： 造船 → 训练船员 → 与单个船员协作 → 并行指挥多个船员 + 一位大副」。
https://www.youtube.com/watch?v=iQyg-KypKAA

# 终端中心主义（造船）

坚持全终端工作，核心理由：
· 手不离键盘 = 维持心流，鼠标切换会强制上下文切换
· 跨设备一致性--同一套工作流可在手机/不同机器上接续

工具栈：WezTerm （跨平台、Lua 配置、热重载） + tmux （会话持久化、多 pane、可远程 attach） + Neovim （键盘优先、相对行号）。

# 船员的入职培训（Memory + Skills）
agent 是新兵，不知道你的偏好。两类机制 ramp up：Memory 和 Skills

1. Memory
· 全局 memory（如 ~/.claude/CLAUDE.md）：保持精简（27 行），因为内容会注入每次会话的系统提示词，过长会"静默"消耗 token
· 几条有洞察的偏好规则：
1. 不要用 em-dash（-）--AI 默认会用，显得机械
2. 做技术决策时不要高估开发成本--模型用人类数据训练，会高估耗时（预估"天/周"，实际几分钟出可玩版本），这种偏差会让模型偏向"便宜但低质量"方案。这条是纠正模型训练偏差
3. bug 修复优先端到端复现，而非依赖单元测试
· 项目级 memory：核心方法不是手写，而是每次纠正 agent 后让它把教训写进去--项目集体学习的沉淀

2. Skills
· 把条件性内容（如仅改代码时才需要的 E2E 说明）从 memory 抽到 skill
· skill 启动时只加载简短描述，用到才读全文--避免无谓 token 消耗

3. 关于 skills 的重要警告
· Karpathy 的 skills 仓库（17.7 万 star）经 program-bench 评测后，使用反而多耗 5% token 且结果更差，且并非 Karpathy 本人所写
· 安全风险：skill 可在机器上执行任意命令，可能泄露 API key 甚至银行凭证
· 结论：流行 ≠ 优质。不要装声称"神奇提升"却无严格评测的 skill

# 与单个船员协作

1. 语音输入
· 几乎全用语音替代打字（Stanford 论文：说话比打字快 3 倍）
· 工具 OpenSuperWhisper：本地 whisper，免费开源，通过 system prompt 注入自定义词汇表提升专有名词识别

2. AXI 标准 （Agent ergonomics）
自创的为 agent 优化工具的设计标准：
· 实测：同样 GitHub 任务，MCP server 比 CLI 多耗 3 倍 token + 2 倍延迟
· 设计原则之一：token 高效输出格式比 JSON 节省 ~40% token
· 启示：给 agent 的工具本身的效率，直接决定 agent 的"油耗"

3. Lavish （交互式规划工件）
针对"agent 返回一堵文字墙难以评审"的痛点：让 agent 生成 HTML 可视化工件，复用项目设计系统，可针对具体元素批注反馈并在浏览器内回传。

# 验证：no-mistakes 流水线（质量基石）

反直觉主张：不要逐个 review diff。
· 理由：AI 写代码太快，逐 diff 审查会让人成为瓶颈且无趣
· 类比：像工程总监一样思考--总监不审 PR，而是通过文化和流程把控质量

流水线在隔离 worktree 中执行：
· 分析会话还原真实意图
· rebase 到最新 main，提前解决冲突
· 对抗式 review（独立上下文窗口）--多数问题在此被捕获自愈，模糊的升级人类
· E2E 测试并录制证据（截图/视频/日志）
· 文档更新 + 链接检查
· 推分支开 PR，持续 babysit 直到合并

PR 呈现：原始意图、变更摘要、测试证据、流水线发现并修复的问题、风险评估。
评审策略：看风险评估决定投入精力。低风险几乎不看 diff（因流水线已覆盖），只对高风险深入。

工作分布洞察：时间花在任务开头（用 Lavish 澄清需求）和结尾（把质量关），中间全交给 AI。中间腾出越多，并行越多。

# 长时间运行：good-night-have-fun

解决"睡觉 8 小时如何让 agent 持续干活"：给目标和停止条件，在循环中迭代。

相比 Claude Code/Codex 的 /go，优势是可精确设置 token 上限 / 迭代上限 / 停止条件--避免睡醒发现周配额耗尽。

# 并行：treehouse + worktree

git worktree 的痛点：起名、记状态、手动清理 = 认知债。treehouse：运行即落入空闲 worktree，关闭 tab 自动释放，treehouse status 一目了然。

# First Mate：大副编排器

并行会话变多后，上下文切换疲惫。

First Mate 是元 agent，替你管理所有船员：你只跟它对话，它自动拆并行子任务、调用 treehouse 建 worktree、跑 no-mistakes、准备 PR。

关键观察：用了 First Mate 后，瓶颈从"agent 执行力"转移到"你想让它做什么"--船长的价值转向战略：理解用户、研究竞争、画好"藏宝图"。

### 引用推文

> Kun Chen：many people asked me to make a video about my complete agentic engineering workflow excited to share it's finally here!!! it took me about 20 hours in total to ...