前Meta主任工程师分享Agentic工程工作流：每天40+生产级PR

核心框架分为四层：造船（终端中心主义，使用WezTerm+tmux+Neovim）、训练船员（Memory+Skills，全局memory仅27行以避免token浪费）、与单个船员协作（语音输入OpenSuperWhisper，自创AXI标准比MCP节省3倍token和2倍延迟）、并行指挥（treehouse管理worktree，First Mate大副编排器）。

验证环节采用no-mistakes流水线，在隔离worktree中执行对抗式review和E2E测试，大幅减少人工review耗时。该工作流强调将时间花在任务开头和结尾，中间全交给AI，瓶颈从agent执行力转移到战略思考。

前 Meta/Microsoft/Atlassian 主任工程师的 Agentic 工程工作流 用这套工作流 @kunchenguid 每天 ship 40-50 个经测试的生产级 PR，他这么形容它：「你是船长，agent 是你的船员，分四层递进: 造船 → 训练船员 → 与单个船员协作 → 并行指挥多个船员 + 一位大副」。 youtube.com/watch?v=iQyg-K… # 终端中心主义(造船) 坚持全终端工作，核心理由： · 手不离键盘 = 维持心流,鼠标切换会强制上下文切换 · 跨设备一致性——同一套工作流可在手机/不同机器上接续 工具栈：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 @kunchenguid 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 record this 45 minutes of walkthrough - it covers everything i do to ship production quality code at an average 40+ PRs/day velocity hope this can be a useful reference to everyone exploring good ways to use AI. and would appreciate a reshare with anyone you think might benefit from this! enjoy! youtu.be/iQyg-KypKAA 🔗 View Quoted Tweet

This report is categorized under AITOP's "How-to" desk, focusing on US frontier AI labs and Silicon Valley technology leaders. Within our cross-regional analytical framework, it directly maps to AI developer toolchains, coding agents, and engineering workflows. Key entities and technical topics under continuous tracking include Kun Chen, Agentic工程, 工作流, 编程助手.

Source attribution: curated from shao__meng (@shao__meng).